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

Я ни в коем случае не специалист, но не будет ли это жутковатым решетом?

А какая разница? Сейчас браузер исполняет JS, с этой хренью он точно так же будет исполнять бинарник. Права те же. Ничего не меняется.
Ну кроме возможности писать на Си.
Так что это скорее хорошо.

ЕМНИП всякие цги-бин можно и так на си писать. Эдик вроде как-то хвастался давно, что на сях пишет в браузер...

Че за бесконечная череда полумер, давайте сразу отдавать по ftp бинарник и запускать. Сначала в песочнице, потом, когда расслабятся, разрешить ее отключать кнопкой «сделать быстрее». А то какие-то браузеры, JS, как будто это какое-то отношение имеет к гипертексту и протоколу для его отдачи.

Разумеется можно, только вот кросплатформенность.
И мы сейчас говорим про код, исполняющийся на стороне клиента. На стороне сервера хоть на форте пиши.
А тут получим вместо ктулхумерзкого ЖС — любой язык. Переводишь его в байткод (жаба, привет) и радуешься жизни.

cgi-bin - это про серверную сторону. WebAssembly - для клиенткой (браузер пользователя). Поэтому рекламная «фишка» JS - «один язык для сервера и клиента» будет (я надеюсь) актуальна для любого языка.

Там рантайм адового размера будет, как и все что связано с asmjs.

Не верю что взлетит. Гугл их в очередной раз пошлет с asm.js. В гуглях считают, что осилят сделать быстрый JIT без костылей.

Слушай, а бинарник под мой powerPC ты уже собрал?
Бинарник это хорошо, но, как показывает практика, для многих даже в масштабе х86 тяжко перейти на АМД64, а ты говоришь про кучу платформ.
«Виртуальная машина» вполне исправит ситуацию.

Транслятор уже есть, зачем нам твоя плохо оттестированная неуниверсальная машина?

WebAssembly делается совместными усилиями Google, Microsoft, Firefox.

Related issue: https://bugs.webkit.org/show_bug.cgi?id=146064

Поэтому рекламная «фишка» JS - «один язык для сервера и клиента» будет (я надеюсь) актуальна для любого языка.

Уже лет семь не пойму, в чем проблема? Выкиньте из этой цепочки никому не нужный браузер и пишите сервер и клиент хоть на тикле.

Примеры приложений, их размеры и т.п.: https://github.com/WebAssembly/design/blob/master/FAQ.md#can-the-polyfill-rea...

Ты такооой умный. Продолжай.

I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers on creating a new standard, WebAssembly, that defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the Web.

https://blog.mozilla.org/luke/2015/06/17/webassembly/

Vit, понимаю, много времени инвестировано в Nodeca и трудно осозновать, что то же самое можно будет сделать с меньшими усилиями на нормальном языке.

Как только ТС уберет тег «веб» с темы, к которой он не относится =)

P.S. черт, это еще и ты.

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

Я ни в коем случае не специалист, но не будет ли это жутковатым решетом?

Всё выглядит так: из цепочки обработки asm.js выкидывают js-кодирование скомпиленной софтины, и «декодирование» оной на клиенте. Меньше кода обработки, меньше дыр, меньше трафика, меньше нагрузка на CPU/RAM.

С/C++

низкоуровневых языках

Когда они стали низкоуровневыми?

Более весомые пруфы будут? Таких тикетов можно вагон найти.

Я очень даже за LLVM в браузерах, но надо не забывать как эпично гугль профукал далвик.

Со времён появления Явы:)

Однажды и её назовут низкоуровневой?

Вполне возможно когда хипстеры продавят язык программирования как в голливудских боевиках — с сиськами, 3Д и виртуальной реальностью, то и Яву начнут называть низкоуровневой:)

О боги, кажется это уже начало конца https://2ch.hk/pr/res/494718.html

Так то серверсайд, а это клиентсайд. Разницу чувствуешь?

Однажды и её назовут низкоуровневой?

Язык java под jvm уже выглядит низкоуровневым на фоне scala.

Когда они стали низкоуровневыми?

Когда rust расправил крылья.

никому не нужный браузер

В наше время пользователю проще и удобнее работать в браузере, чем качать клиент везде, где он может пригодиться.

Вот это дырища будет.

Но вообще непонятно, чем это отличается от всяких плагинов. Тем что не надо будет устанавливать, а эксплоит будет запускаться сам?

В наше время

Потомки, как вы там? Высадились на Марс?

Тааак.

А теперь, будь добр, дай мне это развидеть!

Какие ещё пруфы нужны? Выше по ссылке в блоге Mozilla (а так же в блогах каждого из участников) заявлено, что это совместная работа Google, Mozilla и Microsoft.

Список контрибьюторов какой-нибудь репы можно посмотреть: https://github.com/WebAssembly/design/graphs/contributors

Можно почитать твиты тех, у кого нет блогов: https://twitter.com/jfbastien/

А можно узнать кто такой @jfbastien и его последнее место работы:

Occupation
Systems & Compilers Maven

Google
Sr. Software Engineer, 2012 - present
Compiler engineer on Portable Native Client, currently focusing on performance and security as well as LLVM for portability. I bring portable, fast and secure native code to the Web. Side-project: tune the V8 JavaScript engine on ARM.

Но зачем оно, если есть asm.js? Или у Гугл синдром NIH достаточной силы?

Так это и есть js-style :)

Это следующая ветвь эволюции asm.js. Не NIH, Mozilla ведь тоже причастна.

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

У асмжээса размер конский получится, и набор фич от синтаксиса зависит, а не от потребностей.

не взлетит

Им дали Java, но нет! Не хотят писать апплеты на Java! Хотят жрать говно!

Уж поумнее тех мудаков, которые WebAssembly придумали.

Всё это можно уже очень много лет как делать на Java.

Это следующая ветвь эволюции asm.js

Я пока не понял, в чем эволюция. Этот WebAssembly всё равно будут переводить в asm.js.

Не NIH, Mozilla ведь тоже причастна.

У Мозиллы нет NIH, у Гугла - есть.

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

Why create a new standard when there is already asm.js?

There are two main benefits WebAssembly provides:

• The kind of binary format being considered for WebAssembly can be natively decoded much faster than JS can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40s just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user experience.
  
• By avoiding the simultaneous asm.js constraints of (1) AOT-compilability and (2) good performance even on engines without specific asm.js optimizations, a new standard makes it much easier to add the features required to reach native levels of performance.
  

WebAssembly, “wasm” for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS’s semantics, in order to best serve as common object-level format for multiple source-level programming languages.

asm.js is great, but once engines optimize for it, the parser becomes the hot spot — very hot on mobile devices. Transport compression is required and saves bandwidth, but decompression before parsing hurts. A secondary consideration: JS has a few awkward corners even in its asm.js subset. Finally, once browsers support the WebAssembly syntax natively, JS and wasm can diverge, without introducing unsafe or inappropriate features into JS just for use by compilers sourcing a few radically different programming languages.

https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

Вот именно, что «initially co-expressive with asm.js». Что будет потом - ТНБ знает, а пока это бинарная кодировка asm.js.

Сейчас браузер исполняет JS, с этой хренью он точно так же будет исполнять бинарник. Права те же. Ничего не меняется.

меняется то, что пользователь не может понять содержимое программы. Никто не может, даже Анатолий Вассерман. Это ограничивает Основную Свободу - пользователь должен четко понимать, что происходит на его компьютере.

Некоторое время веб был оплотом Свободы потому, что всем приходилось писать на умопостижимом JS, совершенно у всех были исходники всего. Сейчас мы возвращаемся к тёмым векам, примерно как в эпоху расцвета коммерческого ПО на десктопах. С этим нужно бороться!

+++ чай +++

С этим нужно бороться!

Механизмы уже есть — GPL, BSD и сотни других лицензий говорящих об открытом коде.
Ты же бежишь переписывать всё на питон чтобы код был читающийся.

Ну если будет polyfill в asm.js, то понятно, но они планируют что когда-то не будет? Вон Google до сих пор Dart VM не пропихнула, владея лидирующим в мире браузером, а у них точно получится

Всё выглядит так: из цепочки обработки asm.js выкидывают js-кодирование скомпиленной софтины

Я так понимаю asm.js код начинается с определенного комментария-директивы, что позволяет не задействовать полноценный парсер JS, а использовать специализированный, который понимает только подмножество JS - asm.js

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

asm.js из-за этого не взлетел (и не взлетит). Поэтому рассматривать WA как бинарную упаковку asm.js не корректно. Это все-таки больше LLVM, но в первой реализации обкоцанный.

настала пора писать заглушки «этот сайт открывается только в Mozilla Firefox, скачать его можно по ссылке» :)))