LINUX.ORG.RU
ФорумTalks

WebAssembly: бинарный формат скоро во всех браузерах страны

 , , , ,


0

2

WebAssembly (https://github.com/WebAssembly/design) is a new format for native programs on the web. It aims to support everything that asm.js supports, but allows the VM to sidestep the JS parsing and profiling pipeline entirely. This is a good thing for the VM - less work to support native code.

Although WebAssembly will have polyfill to asm.js, we should support it natively by:

- Having a WebAssembly baseline JIT that's used for fast start-up and some basic execution count profiling.
- An LLVM backend that uses the FTL's LLVM glue and compiler plan scheduling for hot code.

This standard has broad support, and we should continue to participate in discussions about how to make it great.

https://blog.mozilla.org/luke/2015/06/17/webassembly/
https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/working-on-the-future-o...
https://twitter.com/jfbastien/status/611201861245399041

Сейчас единственный способ писать client-side — использовать JS или любой другой язык, который будет транслироваться в JS. Что геморрно, ибо генерировать JopaScript не очень удобно, да и браузеры не в восторге его парсить. WebAssembly - бинарный формат, который проще как генерировать, так и парсить (Из FAQ: исходники по прежнему можно будет просматривать в читаемом виде в developer tools).

В краткосрочной перспективе (в качестве Proof of Concept или MVP) формат будет пригоден для использования под web С/C++ (языки без GC). При чём, (в том числе) можно будет линковать модули написанные на этих низкоуровневых языках из обычного JS. В дальнейшем планируется добавить поддержку других языков, реализовав garbage collected объекты.

Ответ на: комментарий от Vit

Все зависит от того, будет нативная поддержка где-то кроме мозиллы или нет.

asm.js из-за этого не взлетел (и не взлетит)

Если под «поддержкой в браузерах» понимается «поддержка в Chrome» - да, согласен.

Поэтому рассматривать WA как бинарную упаковку asm.js не корректно

Пока - вполне корректно, см. цитату выше.

tailgunner ★★★★★
()
Ответ на: комментарий от Vit

я не настоящий тролль, только учусь :( *смайлик «новичок за рулём»*

спасибо батяня, это же идея! Нужен чекер читаемости. Когда читаемость плохая, скрипт не запускается в мазиле :)

осталось как-то формально описать, «что такое читаемость», в терминах языка.

например, цикломатическая сложность - это читаемость?

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

меняется то, что пользователь не может понять содержимое программы. Никто не может, даже Анатолий Вассерман

Анатолий может и не сможет, а developers tools покажут тебе исходник в текстовом виде. В стартовом посте есть ведь это. не читай @ сразу отвечай?

Will WebAssembly support View Source on the Web?

Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js. Outside the browser, command-line and online tools that convert between text and binary will also be made readily available. Lastly, a scalable form of source maps is also being considered as part of the WebAssembly tooling story.

https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-sup...

RussCox
() автор топика
Ответ на: комментарий от tailgunner

Если под «поддержкой в браузерах» понимается «поддержка в Chrome» - да, согласен.

Хром + Сафари + FF + желательно IE. И легаси для остального через эмулятор.

Пока - вполне корректно, см. цитату выше.

Ответ настоящего математика - абсолютно точный и абсолютно бесполезный. Текущее состояние не имеет особой практической пользы, поэтому нет предмета для обсуждения. Разве что погыгыкать как мозилла над asm.js выделывается.

Vit ★★★★★
()
Последнее исправление: Vit (всего исправлений: 1)
Ответ на: комментарий от Vit

Если под «поддержкой в браузерах» понимается «поддержка в Chrome» - да, согласен.

Хром + FF + желательно IE

Есть FF и Spartan.

Ответ настоящего математика - абсолютно точный и абсолютно бесполезный.

Как же так, я ведь старался!!!111

Текущее состояние не имеет особой практической пользы

Капитан всего лишь имеет сказать, что 1) машинерия для реализации asm.js сейчас подходит и для WebAssembly 2) Гугл согласился обзавестись очень похожей машинерией (возможно, идентичной) - раньше он этого не хотел.

tailgunner ★★★★★
()
Ответ на: комментарий от RussCox

Как говоришь мне из сервлета DOM'ом манипулировать?

да ты же совсем анскильный, даже гуглить не умеешь: https://docs.oracle.com/javase/tutorial/deployment/applet/manipulatingDOMFrom...

причем если там у тебя Scala внутри, то можно на DOM написать (или заюзать - наверняка есть) нормальные DSL, с помощью которых не придется как инвалид вручную ползать по нодам в цикле

stevejobs ★★★★☆
()
Ответ на: комментарий от RussCox

мы же об апплетах говорили

у сервлетов всё еще проще - можно использовать любой ajax фреймворк или вебсокет чтобы связаться с сервлетом и синкать с ним состояние DOMа. Если DOM целиком server side (никакой клиентский js не имзеняет его), то можно не синкать дом, а принимать с сервера команды на изменение дома. Боюсь, правда, все решат, что у тебя не всё хорошо с личной жизнью, и вызовут санитаров.

stevejobs ★★★★☆
()
Ответ на: комментарий от tailgunner

Капитан всего лишь имеет сказать, что 1) машинерия для реализации asm.js сейчас подходит и для WebAssembly

«asm.js» вполне конкретный термин. Там обкоцанное подмножество операций, которое вытягивали за уши из синтаксиса яваскрипта, а не из реальных потребоностей трансляторов. Что-то сделать можно, но будут большие бинарники.

Код, транслированный в asm.js раза в 4 толще нативного яваскрипта (после минификации/gzip). А надо бы наоборот. Одной бинарной упаковкой проблему не решить.

2) Гугл согласился обзавестись очень похожей машинерией (возможно, идентичной) - раньше он этого не хотел.

Ну вот очень надеюсь, что это не закончится пшиком, и что asm.js будет только первой пристрелкой а не финальной LLVM.

Vit ★★★★★
()
Ответ на: комментарий от stevejobs

Тьфу, о них самых, об апплетах. Используй на благо родины, себя и чего угодно. Кстати, а какой дурачок решил что java applets & сервелат = asm.js & co? Одно - замена JS на Java / C#, другое - возможность использовать любой язык (хоть и /пока/ в перспективе).

RussCox
() автор топика

А может и HTML уже сразу заменим? Все ж наверное помнят, как в Opera Mini классно ужимались странички в OBML, как это весело пролезало через полудохлый EDGE.

uuwaan ★★
()
Ответ на: комментарий от Vit

«asm.js» вполне конкретный термин

asm.js - это спека. Для ее эффективной реализации в Mozilla сделали доработки JS-движка, которые в Гугл делать отказались - типа «мы слишком крутые, чтобы пользоваться такими shortcut-ами». И, похоже, их позиция изменилась.

Там обкоцанное подмножество операций, которое вытягивали за уши из синтаксиса яваскрипта, а не из реальных потребоностей трансляторов.

Там ассемблер абстрактной Си-машины в синтаксисе JavaScript.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

И, похоже, их позиция изменилась.

Я не видел чтобы их позщиция озвучивалась и там звучало «asm.js». Сами же авторы webassebmly в качестве одной из фич говорят, что наконец-то не понадобится ограничиваться asm.js

Там ассемблер абстрактной Си-машины в синтаксисе JavaScript.

Разговор о том, что он не интересен потому что не эффективен по размеру, а не о том умеет он сишечку в жээс или нет.

Vit ★★★★★
()

Срань господня, они же заново изобрели Java applets! И ждёт этот WebAssembly такая же судьба.

WARNING ★★★★
()

Теперь клиентский код будет не только обфусцированным и проприетарным, но еще и скомпилированным. Прогресс!

Klymedy ★★★★★
()

По-моему опоздали на 10-15 лет. Как мне кажется, тормоза уже давно не из-за парсинга.

praseodim ★★★★★
()
Ответ на: комментарий от RussCox

Зашёл на первую попавшуюся демку, оно показало прогрессбар, дошло до 100%, потупило и нарисовало алерт про out of memory. Охрененные примеры!

INFOMAN ★★★★★
()

Опять мою идею до реализации стырили. Но тут хоть часть. (На самом деле идея не моя, в Opera Mini/UC/Bolt/etc её уже реализовали, но через жопу, ибо была вдобавок задача впихнуть жирновеб в ресурсы мобильников).

MiniRoboDancer ★☆
()

экие велосипеды, люди на всё пойдут лишь бы не реализовывать высокопроизводительный js

reprimand ★★★★★
()
Ответ на: комментарий от Klymedy

Скрипты нельзя будет читать через telnet.exe/notepad.exe, кака жалость.

MiniRoboDancer ★☆
()
Ответ на: комментарий от next_time

Не, тут одними очками не отделаешься, тут микроскоп нужен.

t184256 ★★★★★
()
Ответ на: комментарий от reprimand

Уже запилил процессор, выполняющий напрямую плейнтекстовые скрипты, умник?

MiniRoboDancer ★☆
()
Ответ на: комментарий от WARNING

Жабоапплеты кагбэ и не умирали. А основная фишка их — доступ к системе и аппаратной криптографии и возможность жабомакакам не осилять веб-технологии (хотя для них уже давно есть Vaadin, GWT и пр.), а вовсе не компилируемость. И в то же время есть недостаток — из-за больших возможностей и слабой песочницы жабоплагин регулярно ломают. Какое отношение всё это имеет к сабжу?

MiniRoboDancer ★☆
()
Ответ на: комментарий от uuwaan

Вот нечего о минижопере в прошедшем времени говорить, благодаря голожопым африканцам с фичерфонами вместо мощных x86-компьютеров по одной штуке на целую семью из пары десятков ртов она ещё долго жить будет. Корпорации сейчас всерьёз взялись за т. н. «третий миллиард» — вотсапы всякие скупают вон, дирижабли с интернетами им запускают. Цивилизованных гейропопиндосов да чуть менее цивилизованных азиатов с латиноамериканцами доить-то уже неинтересно. А за рекламу в минижопере местечковые опсосы хорошо плотят.

MiniRoboDancer ★☆
()
Ответ на: комментарий от MiniRoboDancer

Жабоапплеты кагбэ и не умирали.

Последний раз я жабоаплет на сайте видел лет 7 назад. А так да, живее всех живых.

Какое отношение всё это имеет к сабжу?

Ну так те же яйца, только в профиль. Основные фишки(в теории): мощь, скорость, кросплатформенность. И всё это достигается при помощи скачиваемого бинарника, который исполняется в виртуальной машине.

WARNING ★★★★
()
Ответ на: комментарий от WARNING

Последний раз я жабоаплет на сайте видел лет 7 назад.

На всяких ынтырпрайз банк-клиентах юзается для эцп. При этом некоторые ещё и дырявую 1.6 жабу требуют, лол.

INFOMAN ★★★★★
()

В бинарных форматах скриптов есть своя логика: к примеру, хочешь отключить функцию на страничке, которая не дает выделить мышкой текст? Имей исходник от JS.

Infra_HDC ★★★★★
()
Ответ на: комментарий от tailgunner

Этот WebAssembly всё равно будут переводить в asm.js.

Только до тех пор, пока эту фигню браузеры не будут поддерживать «нативно». Типа обратная совместимость.

DarkEld3r ★★★★★
()
Ответ на: комментарий от MiniRoboDancer

Африканцы – это хорошо, но давеча была встреча в Питере с представителями Оперы, так оне сказале, что серверную часть Оперы Мини дорабатывать и менять не будут, багофиксить тоже. Престо уже далеко не на всех сайтах с разметкой справляется, дальше будет хуже.

uuwaan ★★
()
Ответ на: комментарий от RussCox

что java applets & сервелат = asm.js & co? Одно - замена JS на Java / C#, другое - возможность использовать любой язык (хоть и /пока/ в перспективе).

Вообще-то, JVM без всяких перспектив, уже позволяет использовать множество языков - Python, Ruby, Scala, Clojure. Если брать из популярных. Соотвественно, апплеты можешь писать на них, а не только на Java.

А asm.js & co эта таже хрень - апплеты, только запускаемые в другой вирт. машине. Так что, теже яйца только в профиль.

К тому же, С/С++ будут обрезанцами на такой вирт. машине. И не каждый код С/С++ скомпиляешь. Это равносильно, как сейчас реализовать С/С++ для JVM. Так что тот еще будет гемор по адаптации С/С++ кода на этот ваш asm.js & co.

foror ★★★★★
()

В этом WebAssembly есть одна занятная штука, перечислили: Rust, Go, C# - как платформы для написания этих самых «апплетов». Но нигде нет слова про Java.

И вот интересно, что будет делать Oracle. Ведь если они не запилять Java под эту новую вирт. машину. Кто их знает, встанут в позу, мол чтобы не распыляться на поддержку еще одной вирт. машины.

Но и другие конечно же не смогут это сделать. Ибо про Андроид все в курсе.

В этом случае, Java банально выпиливается C#, т.к. WebAssembly планируют также и под сервера затачивать. И фактически WebAssembly приходит на замену JVM платформы.

foror ★★★★★
()
Ответ на: комментарий от foror

Выбор Rust, Go, C# обусловлен исключительно тем, что над проектом работают Mozilla, Google и MS. Поза Oracle - дело Oracle. Так что пусть выпиливается.

RussCox
() автор топика

Идея в теории может и выглядит безобидной - генерировать байткод для js браузера,

Причем, используя в качестве исходного кода компилируемые языки.

Но ведь на практике, в такой код несложно протолкнуть нечто, трудно поддающееся анализу.

Чем больше runtime, тем в большей степени это платформо-зависимая вещь и уход от песочницы.

Не без асинхронщины т.к. основа even-driven модели и сети. Да и собственно стоит поизучать исходный код hello world для wasm.

Сразу после анонсов, меня несколько разочаровала эта идея и сохраняет неоднозначное отношение, но материалы https://github.com/webassembly/design/ (FAQ и особенно generate.py ;) и демки выглядят достаточно интересными.

Немного «юмора», намекающего как-бы:

- «а давайте html представим в виде бинарного AST-дерева и байткода, понятного браузеру?

Да что там html !!! - txt!, наконец все текстовые форматы!

Потом и алфавит можно сделать в бинарном виде ... Например в Хаффман-кодировании.

Для общения нужны будут специальные машинки ... Так ведь быстрее доходит ;)

Наконец можно пересмотреть практику использования гласных и синонимов в языках.

К чему эти сложности? ...

Подсоединить провода для точного управления или вообще беспроводное ...»

Здесь в некотором смысле может нарушаться как минимум известный принцип управления, когда за выполняющего, выполняют.

swwwfactory ★★
()
Ответ на: комментарий от swwwfactory

Сразу после анонсов, меня несколько разочаровала эта идея и сохраняет неоднозначное отношение

Да охрененная идея. Давно надо было сделать. Этот JS, к чертям собачьим, давно пора выкинуть. И внедрять типизированные языки.

А если еще запилят ручное управление памятью и будет на равных с JVM, то просто улет )

foror ★★★★★
()
Ответ на: комментарий от foror

Так последние версии js и так становятся типизированными в общем-то.

Этот JS, к чертям собачьим, давно пора выкинуть.

Чтобы было побольше альтернатив? ;)

swwwfactory ★★
()
Ответ на: комментарий от foror

А если еще запилят ручное управление памятью и будет на равных с JVM, то просто улет )

будет практически по прожорливости и свопу ничем не уступать java ;)

swwwfactory ★★
()
Ответ на: комментарий от swwwfactory

Разница будет. Одно дело на каждое приложение запускать новую JVM, другое дело, когда вирт. машина прогрета, «заджитина» и запущена как контейнер для множества приложений.

Я щас сам пилю контейнер для приложений на JVM. Да, есть оверхед в 50 Мб из-за висящей JVM, но запуск одного приложения ничего в последствии не стоит. Во-первых, скорость запуска, как у нативных приложений. Во-вторых, расход памяти не превышает 1 Мб на приложение.

foror ★★★★★
()
Ответ на: комментарий от swwwfactory

Так последние версии js и так становятся типизированными в общем-то.

Ну может в es7 будут аннотации типов, как в python 3, впрочем babel это уже позволяет. Но все равно не удобно, не то.

Чтобы было побольше альтернатив? ;)

Ну лидеры четко определятся. Скорее всего будет Go и C#. Если все ок сложится, то еще Java. Ну и С/С++ будут только, если нужно какую нативную либу портануть.

foror ★★★★★
()
Ответ на: комментарий от Vit

Кстати про размер. Армянское радио спросили, будут ли пилить JavaScript -> WebAssembly компилятор. Армянское радио ответило:

JS → wasm will only really make sense once wasm supports GC, and most likely JIT compilation too, which is still quite a while away. This would basically be equivalent to implementing the JS engine in wasm! I mentioned this recently and @BrendanEich accused me of having been taken over by horse_js.

To be clear, wasm's goal isn't to replace JavaScript, it's to supplement it. It's therefore not really a goal at the moment to support JS → wasm, but the features we want to implement will make it possible. I'm not sure it'll be that useful from a developer's perspective, though. You may get some size reduction, but that's about it. From a browser's perspective it may be interesting to have the JS engine implemented in wasm from a pure security perspective.

Значит таки после реализации GC и планируемых высокоуровневых команд с размером таки всё будет отлично?

RussCox
() автор топика
Ответ на: комментарий от RussCox

Значит таки после реализации GC и планируемых высокоуровневых команд с размером таки всё будет отлично?

Будет смахивать на java 2.0. Если они собираются хранить IR, непонятно какого хрена они чешут людям мозг про asm.js, который ближе к LLVM. Надо как-то определиться, и либо снимать крестик либо надевать трусы.

Отлично будет, когда получится писать под браузер на руби и питоне, и это будет кнопеляться во что-то небольшое, а не в пару мегабайт.

Vit ★★★★★
()
6 сентября 2015 г.
Ответ на: комментарий от WARNING

Последний раз я жабоаплет на сайте видел лет 7 назад

Просто по разным сайтам ходим, бывает. Я давеча встречался с формой проверки студбилетов, который для работы без видимых причин нужна была жаба, причём восьмая, с более ранними не работало.

скачиваемого бинарника, который исполняется в виртуальной машине

Разница в том, что браузеры и так у большинства стоят. В отличие от жабы, которую просто так не скачивают. Даже флешплеер уже зачастую просто так не скачивают, потому что он встроен в популярнейший хромог, чего уж говорить о какой-то маргинальщине. Жабу даже если софт для локалхоста требует, то зачастую тащит с собой, а не требует установить заранее. WebAssembly требует лишь наличия мейнстримного браузера, причём не какого-то одного, как NaCl или ActiveX. Мало того, профит для вебхейтеров в том, что можно писать почти на любом языке, а не осилять JS или хотя бы препроцессоры/абстрагированные костылищи типа GWT/Emscripten.

contra_sperm_spero
()
Ответ на: комментарий от uuwaan

Будто она когда-либо на всех сайтах хорошо работала. А в одностолбным режимом всё разметкопроблемы обычно обходятся, тут уже скорее со скриптами проблема. Особенно весело будет, когда на сайты начнут запихивать синтаксически обратно несовместимый ES6 и валиться с ошибками начнёт буквально всё.

( bodqhrohro aka MiniRoboDancer)

contra_sperm_spero
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.