Google, Microsoft, Mozilla и другие объединились для запуска WebAssembly, нового бинарного формата для Web

http://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/
  • Перевод
Google, Microsoft, Mozilla и инженеры проекта WebKit 17 июня сделали анонс, что они объединились для запуска WebAssembly, нового бинарного формата для компилирования веб-приложений.

Веб развивается благодаря стандартам, и, плохо это или хорошо, JavaScript один из них. Однако на протяжении многих лет мы видели много попыток обойти ограничения языка, например, создание компиляторов, которые транслируют код из других языков в JavaScript. Некоторые из этих проектов фокусируются на добавлении новых возможностей в язык (например, TypeScript от Microsoft) или ускорении JavaScript (например, Mozilla asm.js). Сейчас многие из этих проектов объединяются в том или ином виде в WebAssembly.

Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже). Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.

Идея состоит в том, что WebAssembly предоставит разработчикам единый способ компиляции, который в конечном счете станет веб-стандартом, реализованным во всех браузерах.

Файлы JavaScript это простые текстовые файлы, которые скачиваются с сервера и затем парсятся и компилируются движком JavaScript в браузере. Команда WebAssembly решила использовать бинарный формат потому, что код может быть сжат лучше, чем стандартный текстовый JavaScript файл, и потому, что для движка намного быстрее декодировать бинарный формат (до 23 раз быстрее в текущей реализации), чем, например, декодировать asm.js код.

Проект asm.js от Mozilla имеет долгосрочную цель привнести скорости, близкие к нативным в веб. Проект Native Client от Google для запуска нативного кода в браузере имеет похожую цель, но получил относительно небольшое распространение. Похоже на то, что сейчас WebAssembly имеет возможность привнести лучшее от этих проектов в браузеры.

В качестве первого шага, команда WebAssembly ставит цель достичь той же функциональности, что и asm.js (и разработчики смогут использовать ту же утилиту Emscripten для WebAssembly, что они используют для компиляции asm.js кода сейчас).

На этой ранней стадии команда также планирует запустить библиотеку polyfill, которая будет транслировать код WebAssembly в JavaScript таким образом, что он может быть выполнен любым браузером — даже без наличия встроенной поддержки WebAssembly (что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly). Со временем команда разработает больше утилит (компиляторы, дебаггеры и прочие) и добавит поддержку других языков (например, Rust, Go и C#).

Команда обращает внимание на то, что смысл их идеи не заменить JavaScript, а добавить возможность компилировать большое количество других языков для веб. Действительно, шансы таковы, что и JavaScript, и WebAssembly будут использованы вместе, бок о бок. Например, часть приложения может использовать модули WebAssembly (анимация, визуализация, сжатие, и проч.), а пользовательский интерфейс в основном будет написан на JavaScript.

Мы нечасто можем увидеть, что все значимые разработчики браузеров работают вместе над таким проектом, так что что-то определенно стоящее ожидает нас впереди.
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 192
  • –44
    Главный спонсор данного проекта почему-то не указан. Догадываюсь что это АНБ.
    • +25
      Вам надо новый libastral скачать, ваша версия устарела.
    • +28
      Круто! Я ждвадцать лет ждал этого стандарта!

      Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)

      что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly


      Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011), а поддержка стандарта хорошо если будет в IE12. Экстраполируя, необходимости в библиотеке не будет только лет так через 10 минимум.

      • +1
        Как только Микрософт всех пересадит на десятую винду с годовой подпиской и принудительным обновлением, динозавров со старыми браузерами станет значительно меньше, а следовательно и внедрять стандарты в широкие массы станет легче и быстрее.
        • +5
          Особенно в гос. конторах. :)
        • +9
          Особенно меньше их станет на андроидах.
          • +3
            Насколько я знаю, в android 5 уже webkit обновляется отдельно, независимо от прошивки
            • +1
              Это-то да, но вот доля 5-го андроида ничтожнейше мала. И завоюет большинство платформы еще ох как не скоро.
              • 0
                Могу сказать то же самое про windows 10
        • +1
          Вот вот, еще бы стандарты для верстки ввели, причем жесткие, а не как чейчас.
          • +13
            Жесткие стандарты и сейчас есть. Многие знакомые верстальщики выработали собственные жесткие гайдлайны и следуют им. А тот факт, что 80% веб-страниц сделано с нарушениями любых стандартов — это, по-моему, как раз то, что позволило Web вырасти так быстро и вовлечь огромное количество людей и бизнесов в индустрию.
            Низкий порог входа — это драйвер роста, как бы нам с вами не хотелось, чтобы все писали совершенный код по Макконнеллу
          • +2
            >Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011)
            В куче проектов проще реально забить. Я давно сайты даже в IE не тестирую т.к. на моих площадках его доля составляет около 6%. Гораздо полезнее время потратить, чтобы доступность контента для людей с плохим зрением обеспечить, чем тратить кучу времени на поддержку малопопулярных браузеров.
            • 0
              Это кому как, у меня в копаративных проектах все сложнее, обязатаельная поддержка IE8. И без обратной совместимости вообще никак.
              • +3
                А какова доля на ваших площадках людей с плохим зрением?
              • 0
                а поддержка стандарта хорошо если будет в IE12

                IE 12 не будет, вместо него сделали Edge
                • +15
                  Хоть горшком назовите :)
                  • –1
                    Дэк, если они никак не связаны, можно и пепелацом тогда
                • +8
                  Интересно, какой язык лет через 10 станет стандартом де-факто для фронта.
                  Дак по-моему абсолютно очевидно, какой. Такой же, какой и сейчас.
                  • +1
                    > Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)

                    Наверняка тот, который будет самым популярным на бекэнде, не буду тыкать пальцем…

                    *(благодаря подобной же логике вырос node.js)
                  • +10
                    Аллилуя! Аллилуя!
                    Наконец то можно будет выгнать всех js-кодеров и начать писать SPA на хаскеле! :)
                    • +4
                      Так толсто, что даже тонко.
                      • +4
                        Тридцать три монады мне в эндофунктор, да он же прав!
                    • 0
                      Новый бинарный формат для Web

                      От такого заголовка ожидал анонса нового: флеша, джава-апплетов, джава-эф-икс, сильверлайта…
                      • +37
                        Assembler → C → C++ → Javascript → AsmJS → Assembler → C → C++… :D
                        • +4
                          Я очень надеюсь, что до написания «движка ECMAScript -like на WebAssembly» дело не дойдёт :D

                          P.S. уже предвижу срачи на форумах верстальщиков через 5 лет: «У меня Boost 1.67 под Chrome не компилится, что делать?»
                        • +7
                          image
                        • +1
                          D? Тоже хороший язык.
                        • –8
                          Может ли он заменить формат SWF от Adobe? Ну то есть, его можно попытаться использовать как контейнер для всего всего всего (вместо тысяч картинок, JS и CSS файлов), что позволит добиться такой же виральности, как и у Flash.
                          • +6
                            Очень надеюсь, что нет. Флэш — это такая операционка в браузере, у него свои кукисы, дырки, он до сих пор крадёт у меня мои хоткеи, итд., за это его и ненавидят. А это будет возможность сделать быструю pure computation library.
                            • 0
                              Переезжайте уже в 2015: Packaging on the Web.
                            • +13
                              То есть больше никаких исходников по Ctrl-U?
                              И каждый сайт теперь — черный ящик?
                              • 0
                                Как сказать. Раз предоставят полифил для трансляции в JS, значит возможность понять в общих чертах что именно происходит в коде вполне возможно.
                                • +3
                                  На самом деле — это путь к более мощным клиентским скриптам, в которые можно встраивать сокрытую логику, которая раньше была возможна только на сервере
                                  • +2
                                    Это так.
                                    Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
                                    В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
                                    • +4
                                      Не драматизируйте. Нормальный код на asm даже понятнее, чем код на asm.js, ибо используются нормальные низкоуровневые инструкции с запоминаемыми мнемониками, а не хаки, которые их имитируют. Главное не бояться, и бинарный код — вовсе не преграда. Да и наверняка у этого WebAssembly байт-код будет значительно проще, чем x86, всё же промежуточное представление.
                                      • +1
                                        вместо того что бы гадать, посмотрите по ссылке что уже имеется.
                                        Код будет распространятся в AST, что означает декомпиляция будет очень простой.
                                      • +8
                                        а вы сейчас как детектируете подозрительные скрипты? — вручную просматриваете исходники?
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            Код в браузере будет работать быстро и при должном умении и старании не будет жрать столько, сколько сейчас жрет джаваскрипт. В наш век вебгл это особенно важный момент. К этому у разработчиков добавится возможность писать на языках, которые будут хорошо подходить к тем задачам, которые они будут решать и не городить костыли в виде компиляции в джаваскрипт. Я какое-то время назад писал свою фантазию о таком проекте, многим эта идея не понравилась (возможно, не стоило писать её в треде про джаваскрипт), а на мой возгляд, это одно из самых разумных начинаний для улучшения жизни как пользователей, так и разработчиков.
                                        • +4
                                          а чем принципиально отличается «ковыряться в js» от «ковыряться в asm»?
                                          • 0
                                            Ну во первых — есть отличные мониторы того, что делают скрипты. Какую информацию откуда и куда отправляют.
                                            Единственное — круто было бы — возможность выборочно давать доступ по мере возникновения потребности, например, как сейчас реализовано. Жмёшь на загрузить файл — появляется — вы хотите дать доступ к каталогу (не ко всем, а да, к отдельному каталогу)?
                                        • 0
                                          Будет можно переводить в человекочитаемый формат, как я понял. На гитхабе в целях:
                                          define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
                                          • 0
                                            Вы ещё скажите, что каждый екзешник чёрный ящик, а дизассемблеров в природе нет :)

                                            С другой стороны, возможно, обфускация браузерного кода примет новые формы.
                                            • 0
                                              Не надо пугаться
                                              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.

                                              github.com/WebAssembly/design/blob/master/FAQ.md
                                          • 0
                                            Я уже и не думал, что это когда-нибудь произойдет, наконец таки их осенило.
                                            • 0
                                              Думаю, все только выиграют от того что клиентская разработка станет не привязанной жестко к JS, хотя деплой клиентской логики при таком подходе существенно усложнится
                                              • +2
                                                И в чем это будет сложнее чем то, как это работает сейчас?
                                                • –3
                                                  Компиляция
                                                  • +2
                                                    Я не знаток фронтенд-разработки, но вангую, что пайплайн из одного шага (компиляция) проще и короче пайплайна из полудесятка (трансляция, проверка, конкатенация, минификация и прочие -иции).
                                                    • 0
                                                      ну чисто практическая ситуация — кусок кода, который написан для обработки данных, которых пока нет на страничке, но они могут быть туда в какой то момент добавлены аджаксом. Компиляция подразумевает не только преобразование кода, но и установки ссылок на обьекты поздействия, в случае браузера это DOM обекты. Без привязки к структуре DOM вся эта компиляция — пшик, основное время как раз и занимает ползанье по модели, а не интерпретация команд скрипта. Получится очередная надстройка над html которая внутри себя все равно все приведет в реальный для браузера формат.
                                                    • +3
                                                      Ну вы же в курсе, что вроде как в современном вебе вообще принято делать сборку проекта, минификацию файлов, и хорошо бы еще инвалидацию кеша предусмотреть. Так что компиляция — практически и не проблема вовсе.
                                                • 0
                                                  Не могли бы вы подсказать, как это повлияет на судьбы JS разработчиков, по вашему мнению?
                                                  • 0
                                                    Никак. Абсолютно.
                                                    • +1
                                                      Мы будем тратить меньше времени на чёрное шаманство т.е. сейчас, например, быстрые классы как бы есть, но как бы нет. Вроде просто, а начинаешь разбираться в производительности, залезаешь в сгенерированный LIR — ох ёёё. Оптимизация производительности — это изучение плохо документированных фич работы js-движков и борьба с их багами.
                                                      Надо быстро? Взял C++ (неважно, какой язык будет использован на самом деле), написал, скомпилил — всё.
                                                      В остальном всё останется как есть.
                                                      • +3
                                                        Кого не выбросит из профессии необходимость вместо коллбеков использовать промисы и затем вместо промисов использовать йилды да эвэйты (то есть буквально два раза стать с ног на голову после выхода ES5 и затем ES6), того добьёт WebAssembly.
                                                        • +1
                                                          Что нас не убивает – делает сильнее! WebAssembly встретим во всеоружии.
                                                      • +3
                                                        Немалая часть народа, программирующего сегодня фронтенд, к моменту реального запуска уже будет на пенсии.
                                                        • +1
                                                          Почему это Вы так решили? Над проектом работают немало людей, причём из серьёзных компаний. Да ещё и желающие приглашаются.
                                                        • +4
                                                          Я так понимаю что разница между JS и WebAssembly лишь в скорости парсинга. Но не понимаю чего все так ликуют ведь по сути не так много изменится. т.е. будет аля TypeScript на С# с набором абстракций типа DOM'а который как и обычный нужно компилить для браузера и в конечно счете получить тот же JS просто в более компактном виде.

                                                          Если где то ошибся ткните носом. =)
                                                          • 0
                                                            Да, вы правы, разница между JS и WebAssembly лишь в скорости первоначального парсинга. В итоге код будет исполняться движком JS, значит время исполнения будет примерно одинаковое.

                                                            Некоторые люди рады возможности использовать остальные языки (поддержку которых добавят в будущем) для веб-разработки.
                                                            • +5
                                                              Нет, это же будет не синтаксическое дерево, получаемое после парсинга обычного JS, а IR, наподобие того, что генерит сейчас asm.js, но в бинарном виде. Если такой формат будет поддержан браузерами, по скорости выполнения будет почти как нативный код.
                                                              • 0
                                                                Спасибо.
                                                                Да, я не прав, в случае поддержки в браузерах, выполнение будет быстрее.
                                                          • +17
                                                            Внутренний Столлман во мне почуял, что грядут времена проприетарщины на вебе
                                                            • +1
                                                              Ну так и хорошо, что хоть кто-то денег на клиентских(frontend) разработках сможет поднять без риска мгновенного форка
                                                              • 0
                                                                для этого +- подходит только nacl, тут смысл в том что на клиент будет приходить уже распарсенное AST дерево, то есть тот же код, только без комментариев и уже с проставленными аннотациями о типах как в asm.js

                                                                и сами авторы это прямо заявляют, что код можно будет свернуть обратно в некий код для чтения человеком, пруф:
                                                                github.com/WebAssembly/design/blob/master/HighLevelGoals.md
                                                                define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
                                                            • –6
                                                              Это лично мое мнение, но выбор первичных языков огорчает. И честно говоря непонятен, с/с++/с# мало распространены среди веб разработчиков, взялиб JVM языки. Ну хоть гугл пропихнул go, уже кое что. А еще печалит что стек разработки веб приложения, усложняется огромными темпами… Зп веб девов бы так росли.
                                                              • 0
                                                                6 минусов и ни одного комментария… то есть — несогласны, но возразить не чем?!
                                                                • 0
                                                                  Здесь уже несколько раз отвечали на подобные вашим комментарии. Повторяться — удовольствие из малоприятных. C/C++ — это первый обязательный язык для поддержки для любого низкоуровневого байт-кода или машинного кода. Потому что на этом языке написано огромное количество библиотек для всех возможных задач. Наверняка без C++ не обошлось и при разработке Java, и т.д. Это системный язык, и он построен так, чтобы генерировать эффективный машинный код, а не для того, чтобы на нём можно было писать не думая и не понимая как это вообще работает. Вообще если технология взлетит, то под неё быстро напишут кучу разных компиляторов под все популярные языки, для которых вообще возможно сгенерировать эффективный машинный код. В других случаях под WebAssembly будут собирать виртуальные машины, которые будут выполнять байт-код нужного вам языка. В общем, они всё правильно делают. Главное только чтобы этот WebAssembly действительно оказался близким по производительности к нативному коду :)

                                                                  Для вас ничего не изменится. Больше возможностей — лучше. Но вас никто не заставляет изучать их все. Вы как кодили на JavaScript, так и можете продолжать. Под WebAssembly будут программировать другие специалисты, и это актуально только для проектов, где нужна большая производительность на клиенте. Даже если вы захотите использовать это для того, чтобы сжать и оптимизировать картинку/видео на клиенте до отправки на сервер (без флэша) — наверняка для обычных кодеров под веб будут сделаны готовые библиотеки для удобного использования из JavaScript.
                                                                  • 0
                                                                    Спасибо за ответ, вы дали повод для размышлений. На что и надеялся сделав комментарий, а не молча минусы ловить.

                                                                    Я не пишу на js, умею, но не хочу. Так вот, как раз в этой ситуации, писать на с/с++ придётся мне, так как не ограничиваю себя познаниями лишь веб яп. И с этим фактом высказал личное мнение, что мне не нравится выбор языков. И привёл свои мысли на тему популярности с/с++ среди веб разработчиков, ведь технологий много создавалось, вопрос в том будут ли использовать…

                                                                    К тому же, цель проекта получить бинарник для браузера и для этих целей с/с++ не обязателен.

                                                                    П.С. Таки был прав в догадках, сишники минусовали.
                                                                    • +1
                                                                      Ну я не сишник, я вообще PHP-программист. Вам не придётся писать на C/C++, если вы не хотите. Подождёте компилятор языка, который вам нужен, и будете писать на нём. Всё равно после появления стандарта до момента, когда это распространится и можно будет использовать в продакшне пройдёт не один год. За это время все востребованные языки получат свои компиляторы, не переживайте.

                                                                      Цель получить быстрый код. Код на C++ будет быстрее кода на Java, потому что C++ ближе к железу. Эта технология создаётся для тех вещей, которые при помощи JS решались плохо, костыльно (через asm.js), медленно. Соответственно и язык выбран — самый популярный из подобных эффективных и близких к машинному коду языков.

                                                                      А C++ хотя бы поверхностно знать и уметь писать на нём полезно для общего развития. Для понимания как это всё работает, чтобы делать меньше глупостей.
                                                                      • –1
                                                                        Я же написал, что меня огорчает «первичный выбор»… А go меня вполне устраивает. Вы так защищаете си будто я написал что это плохой или никчёмный язык, но ведь, суть моего поста в другом.
                                                                        И да, я писал на сях, не много. Но мне хватило этого для понимания, что я этим пользоваться не хочу. Благо есть компилируемые языки способные заменить си почти в любой ситуации.
                                                                        • 0
                                                                          Я вам объясняю, почему в данном случае C/C++ — наиболее логичный выбор для «первичного выбора». Вас устраивает Go, кого-то устраивает Rust, а промышленный стандарт — C++, и с этим нужно считаться.
                                                                          • –1
                                                                            Еслиб веб относился к промышленным технологиям, у меня вопросов не возникло, но ведь это не так. Я понимаю, что си прекрасно подходит для этой задачи, но у меня сомнения, что он подходит для сферы веб разработки.

                                                                            И кстати ваши мысли, что если я не захочу писать на сях, мол и не придётся… Вы не правы, первым выйдет си и наиболшее количество библиотек выйдет на сях и мне таки придётся как минимум ковырятся в этом.
                                                                            • –2
                                                                              Вы сможете обращаться к модулям написанным на C/C++ из обычного JavaScript.

                                                                              Ваш же вариант, первоочередная реализация JVM, попахивает оверинженерингом и большим оверхидом: по сути каждая бинарная сборка WebAssembly должна будет содержать полный код JVM на байт-коде WebAssembly, в которой будет крутится байт-код Java или Scala
                                                                              • +1
                                                                                К годалке не ходи что код jvm ни кто включать не будет, есть всякие jaccelerator и прочие. Собственно если они надумают включить java в список поддерживаемых языков им и так придется с этим что то делать.

                                                                                Вы серьёзно думаете, что я не понимаю как это будет работать? То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.

                                                                                Предвидя ваше возрожение по поводо либ php — да я туда лажу, приходится.
                                                                                • 0
                                                                                  Если включать в список поддерживаемых JVM языки, в рамках объявленной парадигмы, то есть три пути:

                                                                                  1. игнорировать существующие компиляторы для них и писать компиляторы Java, Scala и т. д. в wasm

                                                                                  2. писать компиляторы байт-кода jvm в wasm или поддерживаемый уже язык (тот же С++)

                                                                                  3. написать jvm на wasm и включать её в загружаемые с сайтов бинарники.

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

                                                                                  То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.

                                                                                  Так код либы будет представлен в виде wasm-кода, на каком языке она была написана изначально мало будет иметь значения, если только нет желания запушить свои изменения в её исходники или поддерживать свой форк её.
                                                                                  • 0
                                                                                    Второй вариант: http://habrahabr.ru/post/240999/
                                                                                    • 0
                                                                                      Интересная смесь подходов 1 и 2: TASTY. Это промежуточное представление для компилятора скалы. А раз уж scalac умеет компилировать и java классы, то, полагаю, это представление будет доступно и для java.

                                                                                      Это фактически голые AST, после всех преобразований. Таким образом компилятор уже сделал всю сложную работу, но у нас все еще не потеряна никакая информация и мы все еще имеем высокоуровневое представление. В частности одна из целей этого формата в scalac — последующая компиляция в JavaScript.

                                                                                      От подхода 1 здесь наличие всей высокоуровневой информации, от подхода 2 — выполнение существующим компилятором всей основной работы.
                                                                • +1
                                                                  Для Javascript может наступить новая эра и это может оказаться совсем ни шуткой.

                                                                  ЗЫ.
                                                                  По всей видимости Javascript превзойдет по сфере применения все остальные языки и будет их вытеснять из традиционных ниш.
                                                                  • 0
                                                                    Разве не уже пытается? NodeJS(iojs) и т.п. под сервер, NW.js под винду, Apache Cordova под мобилки. Увы WebAssembly лишь ускоряет парсинг и уменьшает вес.
                                                                    • +4
                                                                      Да, вы абсолютно правы, но WebAssembly даст гораздо больше.
                                                                      WebAssembly позволит создавать на javascript нативные приложения для различных платформ.
                                                                      Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.

                                                                      • 0
                                                                        WebAssembly в любом случае должен парсится движком (например V8 аля NodeJS(iojs)).
                                                                        т.е. по факту не даст гораздо больше.
                                                                        • 0
                                                                          Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже). Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.


                                                                          Предполагаю, что там есть уже ВМ(VM) а скомпилированный код(b-code) представляет из себя код для это ВМ.

                                                                          PS.
                                                                          Скорее всего, вопрос времени когда нам покажут спецификацию ВМ.
                                                                          • 0
                                                                            Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.


                                                                            Разве это не то о чем мы говорим? Возможно я ошибаюсь. Нужно оригинал почитать будет.
                                                                            • 0
                                                                              Мы гадаем на кофейной гуще.
                                                                              Как бы там ни было, вся суть к выводу языка на новый горизонт и он того стоит.

                                                                              • 0
                                                                                Так смысл то как раз в том, чтобы писать под браузер не на JS, а на других языках, то есть не вывести JS на новый горизонт, а скорее наоборот.

                                                                                Если это дело разовьётся, появятся компиляторы с других языков в WebAssembly, то количество желающих писать на JS может сильно поуменьшиться.
                                                                              • 0
                                                                                Вы почитайте описание на GitHub. К JS это все не имеет никакого отношения, основная цель — задать кроссплатформенный, портабельный IR, в который можно будет компилить (для начала) C и C++.
                                                                          • –2
                                                                            Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.


                                                                            ой не факт )

                                                                            Flash тоже планировали повсеместно заменить на HTML5
                                                                      • 0
                                                                        Хм, интересно, а как же дебажить тогда?..
                                                                        И будут ли ли либы на одном языке доступны для другого языка безо всякой магии (и как надо будет дебажить в этом случае)
                                                                        • 0
                                                                          отвечу сам себе: у них в FAQ это всё сказано
                                                                        • 0
                                                                          О да, как только после многих годов изучения Javascript я его постиг и полюбил, пришли сишники и все испортили. Теперь они будут диктовать мне условия и в вебе. :(
                                                                          • 0
                                                                            Внимательней прочтите. Они не учат браузер работать с C/C++. Они делают формат который быстрей парсится и по пути делают трансляторы. Клиент так и останется на JS. Условно вам делают формат в который можно собирать проект. Не нужно будет использовать минификаторы и т.п.
                                                                            • 0
                                                                              Не Ему, а Вам. :)
                                                                              • 0
                                                                                Поясните.

                                                                                sarcasm ->

                                                                                А слона то я и не заметил.
                                                                                • 0
                                                                                  1. У нас есть 100500+ всяких разных стандартов. Правада, 99.(9) из них использует лишь пара гиков на Альфа Центавре. И ещё один, да, вот тот в пыльном углу, его используют в сепулькарии на Бетельгейзе.
                                                                                  2. Мы же можем придумать ещё один, который заменит те 10 которые всеми уже изучены, чтобы всем НАМ было хорошо. Мы знаем C|C++ и т.п., и всё в наших руках. В конце концов, мы же всё это написали, так? Для того, чтобы сказать о «снижении порога входа» мы оставим трансляцию в байткод на уровне обратной совместимости с Нашими JS Engine.
                                                                                  3.…
                                                                                  4.…
                                                                                  5. Ещё один Web стандарт, используемый непонятно кем и непонятно где.

                                                                                  Но они могут, да, это Плюс. И они реально помогут товарищам, которые любят лепить Паттерны и Архитектуру там где достаточно Костылей и Велосипедов.
                                                                                  И да, конечно, правильным людям с нормальными задачами они тоже помогут. Но это будет другая история.
                                                                                  • +2
                                                                                    1. У нас есть 100500+ всяких разных стандартов. Правада, 99.(9) из них использует лишь пара гиков на Альфа Центавре.
                                                                                    99.(9) == 100.

                                                                                    А вообще, ничо не понял.
                                                                                • +1
                                                                                  Не Ему, а Вам. :)

                                                                                  В этом вы все таки не совсем правы. =)
                                                                                  • 0
                                                                                    Да, ну, конечно «всем нам». Только я его не заказывал, и, подозреваю, что @graycow тоже.
                                                                                    Основывался на Вашей фразе > «Условно вам делают формат в который можно собирать проект».
                                                                                • +2
                                                                                  Ну, не знаю, у них там в FAQ написано:
                                                                                  As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++. However, by integrating with JS at the ES6 Module interface, web developers don't need to write C++ to take advantage of libraries that others have written; reusing a modular C++ library can be as simple as using a module from JS.


                                                                                  Я так понимаю, что на начальном этапе компилировать в .wasm можно будет только из C++. Это приведет к тому, что появятся библиотеки на C++, своя собственная субкультура и пр. Пока появятся компиляторы из других языков, C++ станет де факто стандарт. И, хотя я понимаю, что браузеру будет все-равно из чего .wasm получился, писать не на том, на чем написано большинство библиотек, мне будет неприятно а плюсы прийдется учить почти с нуля. Я не говорю, что так и будет, но вероятность всегда имеется. Хорошо, что хоть разрешили модули подключать из JS.
                                                                                  • 0
                                                                                    Поддерживаю. В С/C++ самом по себе нет ничего плохого, кроме чудовищного оверхеда.
                                                                                    Я свои пределы знаю, Матан учил на троечку-четвёрочку, потому, что мозгов не хватило. Но это моя троечка была, я её заслужил всё-таки, и сдавал без шпор, просто интересно было себя всё-таки проверять. И да, это был не технический вуз.

                                                                                    На JavaScript можно что-то начать писать даже будучи полным неофитом, и не разбираясь вообще в технологиях.
                                                                                    И, если есть желание и стремление можно достичь в целом неплохого уровня, даже рисуя мелкие опусы для всяких нудных задач.

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

                                                                                    А следовательно, не однозначно, но потенциально может сложиться ситуация, когда программирование для Web будет считаться элитарным занятием. Таким, как, например, считается сейчас умение программировать на ассемблере и C\C++.
                                                                                    И не надо говорить, что на самом деле это типа «просто». Нихера это не просто, у кого нет в базе нормального матана и сотни регистров памяти в межушном нервном узле, может просто нехватить потенциала. И, да, я пробовал. Может попробую ещё, но сейчас не вижу смысла, мне хватает JS, и в нём нет оверхеда. Под Windows у меня есть HTML Applications и Windows Scripting Host. Под Linux у меня есть node.js, Rhino, commonjs (lib). Для общих задач я могу использовать NW.js. А так же у меня есть расширения для браузеров и куча других возможностей сделать ВСЁ самому. С приходом компилятора в веб лично моя жизнь может и не усложнится, но вероятность есть.
                                                                                    • +3
                                                                                      На самом деле просто количество инструментов пригодных для web увеличиться, затратные по производительности вещи будут уходить на уровень ниже и их можно будет использовать через js api.
                                                                                • 0
                                                                                  sarcasm ->

                                                                                  Как я Вас понимаю. Эти злые сишники, лепят свои паттерны и архитектуру, где надо и где не надо. И при этом они почему-то считают, что это и есть программирвоание. А нас, JavaScript Developer'ов при этом за людей вообще не признают. И вот сейчас они решили, что JavaScript стал не совсем нужен.
                                                                                • –12
                                                                                  Взять бы туда Swift в качестве основы. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
                                                                                  • –1
                                                                                    Ого, а почему тут Swift не любят?
                                                                                    • 0
                                                                                      Речь идёт про низкоуровневый двоичный код. Как можно взять высокоуровневый текстовый язык в качестве основы для низкоуровневого двоичного кода? Выглядит как глупость, вот и минусы. А компилировать в низкоуровневый двоичный код можно будет всё что угодно (для чего будут написаны соответствующие компиляторы).
                                                                                      • –4
                                                                                        А вот это:
                                                                                        на текущий момент разработчики сфокусировались на C/C++
                                                                                        видимо, тоже глупость?

                                                                                        Не хочу и не могу навязывать свою модель поведения кому-либо, но, обычно, если я не понимаю чей-то коментарий, то либо спрашиваю, либо прохожу мимо…
                                                                                        • +4
                                                                                          Я процитирую чуть больше из статьи:
                                                                                          Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже).
                                                                                          Нет, это не глупость. Это значит, что первые компиляторы появятся для самых популярных системных языков программирования — для C и C++.

                                                                                          Ваш комментарий написан чётко и ясно. Вы предлагаете WebAssembly основать на Swift. Если бы вы выразили желание получить компилятор Swift под WebAssembly — другое дело.
                                                                                          • –4
                                                                                            </зануда>
                                                                                            Вы забыли за собой закрыть.
                                                                                            Ок, специально для вас перефразирую мой первый комментарий:
                                                                                            Вот бы там на Swift сфокусировались. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
                                                                                            • +7
                                                                                              Я вам минусов не ставил, и специально для меня ничего не нужно делать. Я вам просто пояснил наиболее вероятную причину, почему вам прилетело столько минусов, и что ваше предположение что «Swift здесь не любят» скорее всего неверно.

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

                                                                                              Сколько раз встречал случаи, когда кто-то публично огорчался по поводу минусов (а часто пишут, мол ну хоть кто-нибудь написал бы причину, негодяи, прикрываются анонимностью, трусы и т.д.), я писал в личку наиболее вероятную причину, и мне всегда тут же начинали присылать зачем-то кучу оправданий и даже каких-то обвинений. Не удивлён, что мало кто желает описывать причины поставленного минуса. Как оказалось, если человек сам не в состоянии адекватно отнестись к критике в виде минусов (и оценить что не так), то скорее всего и прямое указание причин ничего хорошего не даст.

                                                                                              Хорошо. Будем считать, что вы хотели бы, чтобы разработчики в первую очередь бросили все силы на создание компилятора для языка Swift. Разумно ли это? База существующего кода на C++ намного богаче, чем на Swift. Компиляторы, архиваторы, декодеры аудио/видео/изображений, огромное количество различных библиотек. Полагаю, что и при создании самого Swift не обошлось без C++. То есть от реализации компилятора C++ будет намного больше пользы, чем от компилятора Swift, или Rust, или что там ещё кто-нибудь может захотеть. А когда стандарт будет готов, тогда и сами авторы этих языков смогут создать соответствующие компиляторы под WebAssembly.
                                                                                              • –3
                                                                                                Мне как бы всё равно на минусы (иначе и не пытался бы спорить), но интересна была причина негативного отношения к комменту.
                                                                                                Спасибо, вы назвали возможную — непонимание смысла моего первоначального комментария (либо неправильная формулировка комментария, что, в общем-то, равноценно в данном случае – оценивался не тот смысл, который я вкладывал).
                                                                                                • +3
                                                                                                  Думаю, проблема вашего комментария не в том, что его не поняли, а в том, что он выявляет ваше непонимание. Вы не понимаете того, что новый стандарт не пытается сменить основной язык на что-то вроде свифта, а создает возможность для выполнения высокопроизодительного кода в первую очередь. В этой связи, ваш комментарий звучит несколько неуместным, и особенно неуместен из за предложения проприетарного языка для открытого стандарта.
                                                                                                  • –3
                                                                                                    Спасибо, что разъяснили мне мои же мысли. ;)

                                                                                                    И, к слову, Apple пообещали сделать Swift 2.0 опенсорсным.
                                                                                      • +1
                                                                                        А за что его любить?
                                                                                      • 0
                                                                                        Там просто нет основы как таковой. Вернее она есть, но простому разработчику лезть в неё практически никогда не нужно, как не нужно Swift-разработчику лезть в генерируемый компилятором машинный код, а С++ разработчику в код LLVM. Какая вам разница исполняется ваш код на х86 или ARM и какая вам будет разница исполняется ваш код на JS-движке, JVM или напрямую в машкоды компилируется?
                                                                                      • +2
                                                                                        … также планирует запустить библиотеку polyfill… что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly

                                                                                        Абсурдно — это запускать технологию, под которую никто не будет писать пока _все_ браузеры на неё не перейдут. Тут всё логично.
                                                                                        • +2
                                                                                          Как человек далекий от веба, скажу, что я немного удивлен. Вроде как для тяжелых приложений лет много назад были придуманы Джава-аплеты (компилироваанная Джава) и исполение их в песочнице, предоставляемой браузером. Почему не стали развивать это направление? Чем оно хуже WebAssembly?

                                                                                          Так же удивляюсь до сих пор, что для самого медленного типа связи, веба, стандартом стал самый длинный формат передачи данных — XML и его призводные: SOUP и т.п. и т.д. Получилось «медленно в квадрате»,
                                                                                          • 0
                                                                                            -1 вместо внятного объяснения? Так держать.
                                                                                            • +6
                                                                                              Я не минусил, но попробую объяснить. Апплеты, флэш, сервелат,… предлагалют браузер внутри браузера. Оно бажное, небезопасное, плохо адаптированное к операционке пользователя, проприетарное и избыточное. Всё для работы с UI уже есть, зачем ещё это? Нам не нужна отдельная библиотека контролов вместо DOM. Нам нужна возможность написания кросс-платформенной логики, а желательно ещё и производительность.
                                                                                              Вобщем-то это и есть развитие идеи компилированного кода из апплетов, но «обезжиренное», избавленное от UI и нестандартизованного проприетарного API.
                                                                                              • 0
                                                                                                Про Флэш понятно, это полностью свой фреймворк со своим GUI.
                                                                                                Сервелат — это сервлеты? Они вроде как вообще не про это и испоняются на сервере.
                                                                                                Теперь к апплетам. Если у апплетов и есть своя GUI-библиотека (от Java), то она явно не проприетарная, а очень даже стандартная и кроссплатформенная, как и сама Java. Но что мешает писать на ней только логику?
                                                                                                DOM? Я всегда думал, что это стандарт иерархической структуры сложных документов, а также навигации/поиску по ней. Она уже и GUI-контролы включает?
                                                                                                Еще раз: казалось бы, уж что есть еще более кроссплатформенное, чем Java? Хотя сами исходники закрыты, конечно…
                                                                                                • +2
                                                                                                  Сервелат — silverlight (то же, что флэш, но Microsoft).
                                                                                                  > уж что есть еще более кроссплатформенное, чем Java
                                                                                                  На iOS её нет в принципе. На Windows нет предустановленной. Включать её в браузеры? Просить ставить отдельно (как было в апплетах) — моветон.
                                                                                                  > она явно не проприетарная, а очень даже стандартная
                                                                                                  Jav-у разрабатывает Oracle, а не коммитет из Microsoft+Google+Mozilla+Apple+ещё некоторых.
                                                                                                  > DOM? Она уже и GUI-контролы включает?
                                                                                                  Кнопочки, поля ввода, взаимодействие с ними ит.д. — всё это включает в себя DOM API, и позволять заменять его категорически не надо.
                                                                                                  И получается — как же это развивать? Отобрать jav-у Оракла, выпилить UI, бОльшую часть стандартной библиотеки, оставить только VM (а зачем, когда есть свой)? По-моему, так проще взять уже имеющуюся JS VM и сделать компиляцию под неё.
                                                                                                  • +3
                                                                                                    > она явно не проприетарная, а очень даже стандартная и кроссплатформенная

                                                                                                    … а Оракл вовсе не судится с Гуглом за то, что гугл написал свою реализацию, да? И не пытается доказать в суде, что номенклатура классов и объектов языка защищается копирайтом?
                                                                                            • –4
                                                                                              До изобретения Явы осталось совсем чуть-чуть…
                                                                                              • +5
                                                                                                Это намного более низкоуровневая вещь, чем Java. В нее можно компилить C — попробуйте сделать это с JVM…
                                                                                                • +1
                                                                                                  В нее можно компилить C — попробуйте сделать это с JVM…
                                                                                                  Да вы не поверите

                                                                                                  А человеку минусы поставили незаслуженно.
                                                                                                • +4
                                                                                                  Это скорее LLVM для веба.
                                                                                                • –10
                                                                                                  Новые машины тьюринга, исполняющие недоверенный код, новые дырки в реализации. Лучше бы договорились отключить JavaScript в браузере по умолчанию.
                                                                                                  • +4
                                                                                                    Может и HTML с CSS отключить, чего уж мелочиться.
                                                                                                    • –2
                                                                                                      К HTML с CSS претензий нет, технологии простые. Хотя потуги усложнять их есть.
                                                                                                      • +6
                                                                                                        > К HTML с CSS претензий нет,
                                                                                                        > технологии простые.

                                                                                                        Ооок.
                                                                                                  • –1
                                                                                                    Мне вот интересно, можно ли будет из нативного js прозрачно работать с кодом загруженным в этом формате? Например скомпилировать к примеру node.js, отдать клиенту и вызывать node.js api из js скрипта?
                                                                                                  • 0
                                                                                                    Интересно,
                                                                                                    а что с безопасностью?

                                                                                                    Кто-нибудь посоветует работы, посвященные ИБ в WebAssembly?
                                                                                                    • +3
                                                                                                      да только начали драфты стандарта делать, ещё мало материала который четко обрисовывает даже его принципы, какие работы по безопасности?!
                                                                                                      почитайте про NaCl от Google там про выполнение ассемблерного кода скачанного с интернета на процессоре
                                                                                                    • 0
                                                                                                      Web-разработка на Qt? :) Запуск десктопных программ в браузере?!
                                                                                                    • 0
                                                                                                      аллилуйя!
                                                                                                      • 0
                                                                                                        Почему то никто из здесь собравшихся не обсуждает проблему веса всего этого кода, который будет компилироватся. Тот же boost или qt довольно прилично занимают.
                                                                                                        • +2
                                                                                                          Поработаю кепом: не пользуйтесь boost или qt, если их вес вас беспокоит.
                                                                                                        • –2
                                                                                                          Спираль развития вернулась к модели Java — компиляция в bytecode где-то на стороне — исполнение bytecode в песочнице browser — это наверное хорошо.

                                                                                                          Сомнения вызывает конкретно browser как target песочница.

                                                                                                          У каждой конторы и framework теперь будет свой язык. Хорошо это или плохо для web как платформы?

                                                                                                          Иметь возможность написать ray-tracer какой на некоем подмножестве C/C++ и их runtime на web page это наверное хорошо, но что потом делать с результатами? Ни к HTML ни к CSS этот ray-tracer не пришьёшь. И потом весь web sandbox API предполагает GC.
                                                                                                          Вообще идея программировать на C/C++ в web client вызывает больше вопросов чем ответов. Скорее всего в Web была более полезна модель MSIL/CLR как более продвинутой версии Java .class и runtime.

                                                                                                          Но опять же, что делать с HTML/CSS? По идее их тоже надо «раздевать». Чтобы можно было тот же LESS/SASS имплементирвать «нативно» на клиенте. Или скажем иметь возможность влезать в rendering tree и делать свои layout managers.

                                                                                                          Скорее всего мы наблюдаем начало фазы когда продвинутая общесвенность в конце концов осознала факт что никакой комитет не может толком разработать непротиворечивую платформу которая даст шастя всем и бесплатно. Поэтому эволюция возвращается к истокам — вот вам, пацаны, основы в виде ASM/bytecode и AWT, а дальше творите сами — бой покажет.

                                                                                                          • 0
                                                                                                            Место HTML займет WPF уверен в этом. Получится тот же Silverlight только с черного входа, чтоб никто не заподозрил.
                                                                                                            • 0
                                                                                                              WPF в web не будет никогда. Это точно. HTML худо бедно, но semantic markup.
                                                                                                              Я слабо себе представляю что должно по CTRL-C происходить с выделением на «WPF web странице». И что потом с этим делать.
                                                                                                            • +1
                                                                                                              Ни к HTML ни к CSS этот ray-tracer не пришьёшь.

                                                                                                              DOM доступен точно, вероятно и CSSOM. Собственно, всё что доступно JS в браузере должно быть доступно и WA-коду.
                                                                                                              • –1
                                                                                                                Далеко не всё доступно. Например rendering tree недоступно. А без него не пострить свой собсвенный layout manager. Скажем подправить тот недоделанный flexbox (который вообще недоразумение одно ломающее к тому же существующую box model). Свои length units не добавить. И пр.
                                                                                                                • +1
                                                                                                                  А JS на странице это сейчас может?
                                                                                                            • +1
                                                                                                              Ребята, я немного не понял. То есть теперь веб-приложения потенциально могут состоять из c++ \ c# \ go \ js кода одновременно? Как все это поддерживать? Возможна ли ситуация, когда над проектом будет работать несколько разработчиков и каждый будет писать на языке, который он знает, в итоге превратив код в кашу?
                                                                                                              • +1
                                                                                                                Поддерживать так же, как сейчас emscripten (или нативные компоненты, скажем, в C#). То есть, некий модуль, который пишется на C++ (ну или что там будет), остальное на JavaScript. Теоретически-то возможно, а практически, это я не знаю, как в C# нативный код добавить — т.е. мимо архитектора сам по себе такое вот так просто не появится.
                                                                                                                • –1
                                                                                                                  С emscripten не работал, к сожалению, поэтому не знаю, как там все устроено. Пытаюсь разобраться в такой ситуации: веб-проект писался на C#, C++ и т.д. Ты приходишь устраиваться на работу, как JS разработчик. Сможешь ли ты поддерживать (редактировать, добавлять новый функционал) в модули, написанные на этих языках, зная только JS? Или же будущему веб разработчику нужно будет знать кучу языков?