Веб развивается благодаря стандартам, и, плохо это или хорошо, 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.
Мы нечасто можем увидеть, что все значимые разработчики браузеров работают вместе над таким проектом, так что что-то определенно стоящее ожидает нас впереди.
Комментарии (184)
VolCh
19.06.2015 06:54+28Круто! Я ждвадцать лет ждал этого стандарта!
Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)
что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly
Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011), а поддержка стандарта хорошо если будет в IE12. Экстраполируя, необходимости в библиотеке не будет только лет так через 10 минимум.
Xelonic
19.06.2015 07:35+1Как только Микрософт всех пересадит на десятую винду с годовой подпиской и принудительным обновлением, динозавров со старыми браузерами станет значительно меньше, а следовательно и внедрять стандарты в широкие массы станет легче и быстрее.
vlivyur
19.06.2015 10:22+9Особенно меньше их станет на андроидах.
kwolfy
19.06.2015 13:42+3Насколько я знаю, в android 5 уже webkit обновляется отдельно, независимо от прошивки
romashko_o
19.06.2015 20:13+1Это-то да, но вот доля 5-го андроида ничтожнейше мала. И завоюет большинство платформы еще ох как не скоро.
ZloyHobbit
19.06.2015 08:33+1Вот вот, еще бы стандарты для верстки ввели, причем жесткие, а не как чейчас.
aur
19.06.2015 10:59+13Жесткие стандарты и сейчас есть. Многие знакомые верстальщики выработали собственные жесткие гайдлайны и следуют им. А тот факт, что 80% веб-страниц сделано с нарушениями любых стандартов — это, по-моему, как раз то, что позволило Web вырасти так быстро и вовлечь огромное количество людей и бизнесов в индустрию.
Низкий порог входа — это драйвер роста, как бы нам с вами не хотелось, чтобы все писали совершенный код по Макконнеллу
beduin01
19.06.2015 09:16+2>Абсурдно это для того, кто не знает что такое обратная совместимость. На настоящий момент в требованиях к публичному браузерному коду часто фигурирует IE8 (2009), встречается IE7 (2006), мастхэв IE9 (2011)
В куче проектов проще реально забить. Я давно сайты даже в IE не тестирую т.к. на моих площадках его доля составляет около 6%. Гораздо полезнее время потратить, чтобы доступность контента для людей с плохим зрением обеспечить, чем тратить кучу времени на поддержку малопопулярных браузеров.BOBS13
19.06.2015 15:50Это кому как, у меня в копаративных проектах все сложнее, обязатаельная поддержка IE8. И без обратной совместимости вообще никак.
Elusive_Dream
19.06.2015 10:00а поддержка стандарта хорошо если будет в IE12
IE 12 не будет, вместо него сделали Edge
a553
19.06.2015 10:05+8Интересно, какой язык лет через 10 станет стандартом де-факто для фронта.
Дак по-моему абсолютно очевидно, какой. Такой же, какой и сейчас.
SerafimArts
19.06.2015 14:11+1> Интересно, какой язык лет через 10 станет стандартом де-факто для фронта. Принимаю ставки :)
Наверняка тот, который будет самым популярным на бекэнде, не буду тыкать пальцем…
*(благодаря подобной же логике вырос node.js)
r00tGER
19.06.2015 08:38Новый бинарный формат для Web
От такого заголовка ожидал анонса нового: флеша, джава-апплетов, джава-эф-икс, сильверлайта…
denis_g
19.06.2015 08:59+37Assembler > C > C++ > Javascript > AsmJS > Assembler > C > C++… :D
mapron
19.06.2015 15:51+4Я очень надеюсь, что до написания «движка ECMAScript -like на WebAssembly» дело не дойдёт :D
P.S. уже предвижу срачи на форумах верстальщиков через 5 лет: «У меня Boost 1.67 под Chrome не компилится, что делать?»
WarAngel_alk
19.06.2015 20:04+1Это ещё не самые смелые предсказания!
www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
sandricmora
19.06.2015 23:21+7
jetman
19.06.2015 09:33-8Может ли он заменить формат SWF от Adobe? Ну то есть, его можно попытаться использовать как контейнер для всего всего всего (вместо тысяч картинок, JS и CSS файлов), что позволит добиться такой же виральности, как и у Flash.
Antelle
19.06.2015 09:53+6Очень надеюсь, что нет. Флэш — это такая операционка в браузере, у него свои кукисы,
дырки,он до сих пор крадёт у меня мои хоткеи, итд., за это его и ненавидят. А это будет возможность сделать быструю pure computation library.
crackpot
19.06.2015 09:41+13То есть больше никаких исходников по Ctrl-U?
И каждый сайт теперь — черный ящик?
radist2s
19.06.2015 09:50Как сказать. Раз предоставят полифил для трансляции в JS, значит возможность понять в общих чертах что именно происходит в коде вполне возможно.
Mistx
19.06.2015 09:58+3На самом деле — это путь к более мощным клиентским скриптам, в которые можно встраивать сокрытую логику, которая раньше была возможна только на сервере
crackpot
19.06.2015 10:03+2Это так.
Но вот банальный и попсовый кейс: кто-то хакнул чей-то сайт и вместе с контентом прилетает обфусцированный «злой» код на JS. Это противно, но понимаемо — код можно развернуть и понять что и как.
В случае же бинарных данных — что делать? Всем срочно учить asm, дизассемблировать бинарники и ковыряться? По мне — для предприятий проще будет забанить на уровне корпоративной прокси получение таких данных, а за корпоративными проксиками так или иначе находится приличный процент веб-аудитории.
VEG
19.06.2015 10:16+4Не драматизируйте. Нормальный код на asm даже понятнее, чем код на asm.js, ибо используются нормальные низкоуровневые инструкции с запоминаемыми мнемониками, а не хаки, которые их имитируют. Главное не бояться, и бинарный код — вовсе не преграда. Да и наверняка у этого WebAssembly байт-код будет значительно проще, чем x86, всё же промежуточное представление.
knott
19.06.2015 12:43+1вместо того что бы гадать, посмотрите по ссылке что уже имеется.
Код будет распространятся в AST, что означает декомпиляция будет очень простой.
neolink
19.06.2015 10:19+8а вы сейчас как детектируете подозрительные скрипты? — вручную просматриваете исходники?
ntfs1984
19.06.2015 10:48-2Все мы так делаем.
И хуже всего даже не подозрительный скрипт, а не рабочий. Раньше код можно было изменять на лету, и например я применяю эту фичу очень часто (ближайший пример — реалтаймовый чат на Одеске) и будет очень плохо если такая возможность пропадет.
Плюс ко всему не совсем ясны мотивы, уж простите за мою устаревшую версию libastral: то что размер винды (как и *никсов) из года в год растет и становится тормознутее при функционале по сути все той же 98-й винды — никого не смущает. То что Firefox при 5 открытых вкладках жрет 1 Гб ОЗУ — тоже никого не смущает. Зато «WebAssembly может декодировать код значительно быстрее».
Далее. Скептически отношусь вообще к маркетинговым словам «может декодировать код значительно быстрее». То есть запущенный Javascript работает медленно, а запущенный Javascript с скомпилированным приложением, которое транслируется в Javascript — будет быстрее?
И наконец, что поменяется для конечного клиента? Google начнет быстрее искать? Или скорость соединения увеличивается?
Ой не над тем работают эти ребята…
fogone
19.06.2015 11:12Код в браузере будет работать быстро и при должном умении и старании не будет жрать столько, сколько сейчас жрет джаваскрипт. В наш век вебгл это особенно важный момент. К этому у разработчиков добавится возможность писать на языках, которые будут хорошо подходить к тем задачам, которые они будут решать и не городить костыли в виде компиляции в джаваскрипт. Я какое-то время назад писал свою фантазию о таком проекте, многим эта идея не понравилась (возможно, не стоило писать её в треде про джаваскрипт), а на мой возгляд, это одно из самых разумных начинаний для улучшения жизни как пользователей, так и разработчиков.
niq
19.06.2015 12:45Будет можно переводить в человекочитаемый формат, как я понял. На гитхабе в целях:
define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
VolCh
19.06.2015 14:44Вы ещё скажите, что каждый екзешник чёрный ящик, а дизассемблеров в природе нет :)
С другой стороны, возможно, обфускация браузерного кода примет новые формы.
Mistx
19.06.2015 09:49Думаю, все только выиграют от того что клиентская разработка станет не привязанной жестко к JS, хотя деплой клиентской логики при таком подходе существенно усложнится
radist2s
19.06.2015 09:51+2И в чем это будет сложнее чем то, как это работает сейчас?
Mistx
19.06.2015 10:04-3Компиляция
Ivanhoe
19.06.2015 11:25+2Я не знаток фронтенд-разработки, но вангую, что пайплайн из одного шага (компиляция) проще и короче пайплайна из полудесятка (трансляция, проверка, конкатенация, минификация и прочие -иции).
radist2s
19.06.2015 11:26+3Ну вы же в курсе, что вроде как в современном вебе вообще принято делать сборку проекта, минификацию файлов, и хорошо бы еще инвалидацию кеша предусмотреть. Так что компиляция — практически и не проблема вовсе.
nomn
19.06.2015 09:59Не могли бы вы подсказать, как это повлияет на судьбы JS разработчиков, по вашему мнению?
Antelle
19.06.2015 10:14+1Мы будем тратить меньше времени на чёрное шаманство т.е. сейчас, например, быстрые классы как бы есть, но как бы нет. Вроде просто, а начинаешь разбираться в производительности, залезаешь в сгенерированный LIR — ох ёёё. Оптимизация производительности — это изучение плохо документированных фич работы js-движков и борьба с их багами.
Надо быстро? Взял C++ (неважно, какой язык будет использован на самом деле), написал, скомпилил — всё.
В остальном всё останется как есть.
sergof
19.06.2015 10:00+3Немалая часть народа, программирующего сегодня фронтенд, к моменту реального запуска уже будет на пенсии.
Elusive_Dream
19.06.2015 10:13+1Почему это Вы так решили? Над проектом работают немало людей, причём из серьёзных компаний. Да ещё и желающие приглашаются.
IncorrecTSW
19.06.2015 10:06+4Я так понимаю что разница между JS и WebAssembly лишь в скорости парсинга. Но не понимаю чего все так ликуют ведь по сути не так много изменится. т.е. будет аля TypeScript на С# с набором абстракций типа DOM'а который как и обычный нужно компилить для браузера и в конечно счете получить тот же JS просто в более компактном виде.
Если где то ошибся ткните носом. =)2tl Автор
19.06.2015 12:48Да, вы правы, разница между JS и WebAssembly лишь в скорости первоначального парсинга. В итоге код будет исполняться движком JS, значит время исполнения будет примерно одинаковое.
Некоторые люди рады возможности использовать остальные языки (поддержку которых добавят в будущем) для веб-разработки.Antelle
19.06.2015 13:13+5Нет, это же будет не синтаксическое дерево, получаемое после парсинга обычного JS, а IR, наподобие того, что генерит сейчас asm.js, но в бинарном виде. Если такой формат будет поддержан браузерами, по скорости выполнения будет почти как нативный код.
2tl Автор
19.06.2015 13:33Спасибо.
Да, я не прав, в случае поддержки в браузерах, выполнение будет быстрее.
Alexeyco
19.06.2015 10:11+17Внутренний Столлман во мне почуял, что грядут времена проприетарщины на вебе
Mistx
19.06.2015 10:33+1Ну так и хорошо, что хоть кто-то денег на клиентских(frontend) разработках сможет поднять без риска мгновенного форка
neolink
19.06.2015 10:43для этого +- подходит только 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.
Casus
19.06.2015 11:21-6Это лично мое мнение, но выбор первичных языков огорчает. И честно говоря непонятен, с/с++/с# мало распространены среди веб разработчиков, взялиб JVM языки. Ну хоть гугл пропихнул go, уже кое что. А еще печалит что стек разработки веб приложения, усложняется огромными темпами… Зп веб девов бы так росли.
Casus
25.06.2015 17:366 минусов и ни одного комментария… то есть — несогласны, но возразить не чем?!
VEG
25.06.2015 18:37Здесь уже несколько раз отвечали на подобные вашим комментарии. Повторяться — удовольствие из малоприятных. C/C++ — это первый обязательный язык для поддержки для любого низкоуровневого байт-кода или машинного кода. Потому что на этом языке написано огромное количество библиотек для всех возможных задач. Наверняка без C++ не обошлось и при разработке Java, и т.д. Это системный язык, и он построен так, чтобы генерировать эффективный машинный код, а не для того, чтобы на нём можно было писать не думая и не понимая как это вообще работает. Вообще если технология взлетит, то под неё быстро напишут кучу разных компиляторов под все популярные языки, для которых вообще возможно сгенерировать эффективный машинный код. В других случаях под WebAssembly будут собирать виртуальные машины, которые будут выполнять байт-код нужного вам языка. В общем, они всё правильно делают. Главное только чтобы этот WebAssembly действительно оказался близким по производительности к нативному коду :)
Для вас ничего не изменится. Больше возможностей — лучше. Но вас никто не заставляет изучать их все. Вы как кодили на JavaScript, так и можете продолжать. Под WebAssembly будут программировать другие специалисты, и это актуально только для проектов, где нужна большая производительность на клиенте. Даже если вы захотите использовать это для того, чтобы сжать и оптимизировать картинку/видео на клиенте до отправки на сервер (без флэша) — наверняка для обычных кодеров под веб будут сделаны готовые библиотеки для удобного использования из JavaScript.Casus
25.06.2015 20:44Спасибо за ответ, вы дали повод для размышлений. На что и надеялся сделав комментарий, а не молча минусы ловить.
Я не пишу на js, умею, но не хочу. Так вот, как раз в этой ситуации, писать на с/с++ придётся мне, так как не ограничиваю себя познаниями лишь веб яп. И с этим фактом высказал личное мнение, что мне не нравится выбор языков. И привёл свои мысли на тему популярности с/с++ среди веб разработчиков, ведь технологий много создавалось, вопрос в том будут ли использовать…
К тому же, цель проекта получить бинарник для браузера и для этих целей с/с++ не обязателен.
П.С. Таки был прав в догадках, сишники минусовали.VEG
25.06.2015 20:53+1Ну я не сишник, я вообще PHP-программист. Вам не придётся писать на C/C++, если вы не хотите. Подождёте компилятор языка, который вам нужен, и будете писать на нём. Всё равно после появления стандарта до момента, когда это распространится и можно будет использовать в продакшне пройдёт не один год. За это время все востребованные языки получат свои компиляторы, не переживайте.
Цель получить быстрый код. Код на C++ будет быстрее кода на Java, потому что C++ ближе к железу. Эта технология создаётся для тех вещей, которые при помощи JS решались плохо, костыльно (через asm.js), медленно. Соответственно и язык выбран — самый популярный из подобных эффективных и близких к машинному коду языков.
А C++ хотя бы поверхностно знать и уметь писать на нём полезно для общего развития. Для понимания как это всё работает, чтобы делать меньше глупостей.Casus
26.06.2015 11:38-1Я же написал, что меня огорчает «первичный выбор»… А go меня вполне устраивает. Вы так защищаете си будто я написал что это плохой или никчёмный язык, но ведь, суть моего поста в другом.
И да, я писал на сях, не много. Но мне хватило этого для понимания, что я этим пользоваться не хочу. Благо есть компилируемые языки способные заменить си почти в любой ситуации.VEG
26.06.2015 11:59Я вам объясняю, почему в данном случае C/C++ — наиболее логичный выбор для «первичного выбора». Вас устраивает Go, кого-то устраивает Rust, а промышленный стандарт — C++, и с этим нужно считаться.
Casus
26.06.2015 13:04-1Еслиб веб относился к промышленным технологиям, у меня вопросов не возникло, но ведь это не так. Я понимаю, что си прекрасно подходит для этой задачи, но у меня сомнения, что он подходит для сферы веб разработки.
И кстати ваши мысли, что если я не захочу писать на сях, мол и не придётся… Вы не правы, первым выйдет си и наиболшее количество библиотек выйдет на сях и мне таки придётся как минимум ковырятся в этом.VolCh
26.06.2015 17:32-2Вы сможете обращаться к модулям написанным на C/C++ из обычного JavaScript.
Ваш же вариант, первоочередная реализация JVM, попахивает оверинженерингом и большим оверхидом: по сути каждая бинарная сборка WebAssembly должна будет содержать полный код JVM на байт-коде WebAssembly, в которой будет крутится байт-код Java или ScalaCasus
27.06.2015 11:51+1К годалке не ходи что код jvm ни кто включать не будет, есть всякие jaccelerator и прочие. Собственно если они надумают включить java в список поддерживаемых языков им и так придется с этим что то делать.
Вы серьёзно думаете, что я не понимаю как это будет работать? То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.
Предвидя ваше возрожение по поводо либ php — да я туда лажу, приходится.VolCh
28.06.2015 13:51Если включать в список поддерживаемых JVM языки, в рамках объявленной парадигмы, то есть три пути:
1. игнорировать существующие компиляторы для них и писать компиляторы Java, Scala и т. д. в wasm
2. писать компиляторы байт-кода jvm в wasm или поддерживаемый уже язык (тот же С++)
3. написать jvm на wasm и включать её в загружаемые с сайтов бинарники.
Первый вариант совсем маловероятен. Второй в принципе возможен, но видится много подводных камней, особенно если компилять не напрямую в wasm. Третий будет оверхидный по ресурсам, но, имхо, обеспечит лучшую переносимость.
То что либу дергают из js ни как не влияет на то что придётся лезть в код самой либы.
Так код либы будет представлен в виде wasm-кода, на каком языке она была написана изначально мало будет иметь значения, если только нет желания запушить свои изменения в её исходники или поддерживать свой форк её.senia
28.06.2015 21:06Интересная смесь подходов 1 и 2: TASTY. Это промежуточное представление для компилятора скалы. А раз уж scalac умеет компилировать и java классы, то, полагаю, это представление будет доступно и для java.
Это фактически голые AST, после всех преобразований. Таким образом компилятор уже сделал всю сложную работу, но у нас все еще не потеряна никакая информация и мы все еще имеем высокоуровневое представление. В частности одна из целей этого формата в scalac — последующая компиляция в JavaScript.
От подхода 1 здесь наличие всей высокоуровневой информации, от подхода 2 — выполнение существующим компилятором всей основной работы.
Prapor
19.06.2015 11:22+1Для Javascript может наступить новая эра и это может оказаться совсем ни шуткой.
ЗЫ.
По всей видимости Javascript превзойдет по сфере применения все остальные языки и будет их вытеснять из традиционных ниш.IncorrecTSW
19.06.2015 12:03Разве не уже пытается? NodeJS(iojs) и т.п. под сервер, NW.js под винду, Apache Cordova под мобилки. Увы WebAssembly лишь ускоряет парсинг и уменьшает вес.
Prapor
19.06.2015 12:07+4Да, вы абсолютно правы, но WebAssembly даст гораздо больше.
WebAssembly позволит создавать на javascript нативные приложения для различных платформ.
Считаю, что даже такой монстр как Java в скором времени уступит свою пальму первенства.
IncorrecTSW
19.06.2015 12:16WebAssembly в любом случае должен парсится движком (например V8 аля NodeJS(iojs)).
т.е. по факту не даст гораздо больше.Prapor
19.06.2015 12:18Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже). Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.
Предполагаю, что там есть уже ВМ(VM) а скомпилированный код(b-code) представляет из себя код для это ВМ.
PS.
Скорее всего, вопрос времени когда нам покажут спецификацию ВМ.IncorrecTSW
19.06.2015 12:20Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.
Разве это не то о чем мы говорим? Возможно я ошибаюсь. Нужно оригинал почитать будет.Prapor
19.06.2015 12:30Мы гадаем на кофейной гуще.
Как бы там ни было, вся суть к выводу языка на новый горизонт и он того стоит.
stepik777
19.06.2015 20:58Так смысл то как раз в том, чтобы писать под браузер не на JS, а на других языках, то есть не вывести JS на новый горизонт, а скорее наоборот.
Если это дело разовьётся, появятся компиляторы с других языков в WebAssembly, то количество желающих писать на JS может сильно поуменьшиться.
int19h
20.06.2015 02:13Вы почитайте описание на GitHub. К JS это все не имеет никакого отношения, основная цель — задать кроссплатформенный, портабельный IR, в который можно будет компилить (для начала) C и C++.
graycrow
19.06.2015 11:58О да, как только после многих годов изучения Javascript я его постиг и полюбил, пришли сишники и все испортили. Теперь они будут диктовать мне условия и в вебе. :(
IncorrecTSW
19.06.2015 12:07Внимательней прочтите. Они не учат браузер работать с C/C++. Они делают формат который быстрей парсится и по пути делают трансляторы. Клиент так и останется на JS. Условно вам делают формат в который можно собирать проект. Не нужно будет использовать минификаторы и т.п.
wentout
19.06.2015 12:10Не Ему, а Вам. :)
IncorrecTSW
19.06.2015 12:12Поясните.
sarcasm ->
А слона то я и не заметил.wentout
19.06.2015 12:241. У нас есть 100500+ всяких разных стандартов. Правада, 99.(9) из них использует лишь пара гиков на Альфа Центавре. И ещё один, да, вот тот в пыльном углу, его используют в сепулькарии на Бетельгейзе.
2. Мы же можем придумать ещё один, который заменит те 10 которые всеми уже изучены, чтобы всем НАМ было хорошо. Мы знаем C|C++ и т.п., и всё в наших руках. В конце концов, мы же всё это написали, так? Для того, чтобы сказать о «снижении порога входа» мы оставим трансляцию в байткод на уровне обратной совместимости с Нашими JS Engine.
3.…
4.…
5. Ещё один Web стандарт, используемый непонятно кем и непонятно где.
Но они могут, да, это Плюс. И они реально помогут товарищам, которые любят лепить Паттерны и Архитектуру там где достаточно Костылей и Велосипедов.
И да, конечно, правильным людям с нормальными задачами они тоже помогут. Но это будет другая история.
dbanet
22.06.2015 05:23+21. У нас есть 100500+ всяких разных стандартов. Правада, 99.(9) из них использует лишь пара гиков на Альфа Центавре.
99.(9) == 100.
А вообще, ничо не понял.
IncorrecTSW
19.06.2015 12:23+1Не Ему, а Вам. :)
В этом вы все таки не совсем правы. =)wentout
19.06.2015 12:28Да, ну, конечно «всем нам». Только я его не заказывал, и, подозреваю, что @graycow тоже.
Основывался на Вашей фразе > «Условно вам делают формат в который можно собирать проект».
graycrow
19.06.2015 12:27+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.wentout
19.06.2015 12:45Поддерживаю. В С/C++ самом по себе нет ничего плохого, кроме чудовищного оверхеда.
Я свои пределы знаю, Матан учил на троечку-четвёрочку, потому, что мозгов не хватило. Но это моя троечка была, я её заслужил всё-таки, и сдавал без шпор, просто интересно было себя всё-таки проверять. И да, это был не технический вуз.
На JavaScript можно что-то начать писать даже будучи полным неофитом, и не разбираясь вообще в технологиях.
И, если есть желание и стремление можно достичь в целом неплохого уровня, даже рисуя мелкие опусы для всяких нудных задач.
Предлагаемый подход может изменить векторы приоритетов. Т.к. написание любого «мало-мальски» кода на любом «нормальном» языке, требующем запуска «компилятора» по определению не может быть простым, надеюсь это очевидно.
А следовательно, не однозначно, но потенциально может сложиться ситуация, когда программирование для Web будет считаться элитарным занятием. Таким, как, например, считается сейчас умение программировать на ассемблере и C\C++.
И не надо говорить, что на самом деле это типа «просто». Нихера это не просто, у кого нет в базе нормального матана и сотни регистров памяти в межушном нервном узле, может просто нехватить потенциала. И, да, я пробовал. Может попробую ещё, но сейчас не вижу смысла, мне хватает JS, и в нём нет оверхеда. Под Windows у меня есть HTML Applications и Windows Scripting Host. Под Linux у меня есть node.js, Rhino, commonjs (lib). Для общих задач я могу использовать NW.js. А так же у меня есть расширения для браузеров и куча других возможностей сделать ВСЁ самому. С приходом компилятора в веб лично моя жизнь может и не усложнится, но вероятность есть.
mediaton
20.06.2015 17:33+3На самом деле просто количество инструментов пригодных для web увеличиться, затратные по производительности вещи будут уходить на уровень ниже и их можно будет использовать через js api.
wentout
19.06.2015 12:11sarcasm ->
Как я Вас понимаю. Эти злые сишники, лепят свои паттерны и архитектуру, где надо и где не надо. И при этом они почему-то считают, что это и есть программирвоание. А нас, JavaScript Developer'ов при этом за людей вообще не признают. И вот сейчас они решили, что JavaScript стал не совсем нужен.
norlin
19.06.2015 12:04-12Взять бы туда Swift в качестве основы. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
norlin
20.06.2015 17:21-1Ого, а почему тут Swift не любят?
VEG
20.06.2015 17:34Речь идёт про низкоуровневый двоичный код. Как можно взять высокоуровневый текстовый язык в качестве основы для низкоуровневого двоичного кода? Выглядит как глупость, вот и минусы. А компилировать в низкоуровневый двоичный код можно будет всё что угодно (для чего будут написаны соответствующие компиляторы).
norlin
20.06.2015 17:37-4А вот это:
на текущий момент разработчики сфокусировались на C/C++
видимо, тоже глупость?
Не хочу и не могу навязывать свою модель поведения кому-либо, но, обычно, если я не понимаю чей-то коментарий, то либо спрашиваю, либо прохожу мимо…VEG
20.06.2015 17:53+4Я процитирую чуть больше из статьи:
Новый формат позволяет программистам компилировать их код для браузера (на текущий момент разработчики сфокусировались на C/C++, другие языки будут добавлены позже).
Нет, это не глупость. Это значит, что первые компиляторы появятся для самых популярных системных языков программирования — для C и C++.
Ваш комментарий написан чётко и ясно. Вы предлагаете WebAssembly основать на Swift. Если бы вы выразили желание получить компилятор Swift под WebAssembly — другое дело.norlin
21.06.2015 12:31-4</зануда>
Вы забыли за собой закрыть.
Ок, специально для вас перефразирую мой первый комментарий:
Вот бы там на Swift сфокусировались. Синтаксис очень простой, похож на JS, при этом с типизацией и т.д.
VEG
21.06.2015 13:02+7Я вам минусов не ставил, и специально для меня ничего не нужно делать. Я вам просто пояснил наиболее вероятную причину, почему вам прилетело столько минусов, и что ваше предположение что «Swift здесь не любят» скорее всего неверно.
Смысл у вашей новой формулировки отличается от первоначального. Вместо того, чтобы признать, что высказались неправильно, зачем-то пытаетесь оправдаться.
Сколько раз встречал случаи, когда кто-то публично огорчался по поводу минусов (а часто пишут, мол ну хоть кто-нибудь написал бы причину, негодяи, прикрываются анонимностью, трусы и т.д.), я писал в личку наиболее вероятную причину, и мне всегда тут же начинали присылать зачем-то кучу оправданий и даже каких-то обвинений. Не удивлён, что мало кто желает описывать причины поставленного минуса. Как оказалось, если человек сам не в состоянии адекватно отнестись к критике в виде минусов (и оценить что не так), то скорее всего и прямое указание причин ничего хорошего не даст.
Хорошо. Будем считать, что вы хотели бы, чтобы разработчики в первую очередь бросили все силы на создание компилятора для языка Swift. Разумно ли это? База существующего кода на C++ намного богаче, чем на Swift. Компиляторы, архиваторы, декодеры аудио/видео/изображений, огромное количество различных библиотек. Полагаю, что и при создании самого Swift не обошлось без C++. То есть от реализации компилятора C++ будет намного больше пользы, чем от компилятора Swift, или Rust, или что там ещё кто-нибудь может захотеть. А когда стандарт будет готов, тогда и сами авторы этих языков смогут создать соответствующие компиляторы под WebAssembly.norlin
21.06.2015 14:11-3Мне как бы всё равно на минусы (иначе и не пытался бы спорить), но интересна была причина негативного отношения к комменту.
Спасибо, вы назвали возможную — непонимание смысла моего первоначального комментария (либо неправильная формулировка комментария, что, в общем-то, равноценно в данном случае – оценивался не тот смысл, который я вкладывал).fogone
21.06.2015 18:59+3Думаю, проблема вашего комментария не в том, что его не поняли, а в том, что он выявляет ваше непонимание. Вы не понимаете того, что новый стандарт не пытается сменить основной язык на что-то вроде свифта, а создает возможность для выполнения высокопроизодительного кода в первую очередь. В этой связи, ваш комментарий звучит несколько неуместным, и особенно неуместен из за предложения проприетарного языка для открытого стандарта.
VolCh
22.06.2015 07:44Там просто нет основы как таковой. Вернее она есть, но простому разработчику лезть в неё практически никогда не нужно, как не нужно Swift-разработчику лезть в генерируемый компилятором машинный код, а С++ разработчику в код LLVM. Какая вам разница исполняется ваш код на х86 или ARM и какая вам будет разница исполняется ваш код на JS-движке, JVM или напрямую в машкоды компилируется?
gaelpa
19.06.2015 13:02+2… также планирует запустить библиотеку polyfill… что, очевидно, абсурдно, потому что необходимость в этой библиотеке отпадет, как только браузеры получат встроенную поддержку WebAssembly
Абсурдно — это запускать технологию, под которую никто не будет писать пока _все_ браузеры на неё не перейдут. Тут всё логично.
dyadyaSerezha
19.06.2015 13:29+2Как человек далекий от веба, скажу, что я немного удивлен. Вроде как для тяжелых приложений лет много назад были придуманы Джава-аплеты (компилироваанная Джава) и исполение их в песочнице, предоставляемой браузером. Почему не стали развивать это направление? Чем оно хуже WebAssembly?
Так же удивляюсь до сих пор, что для самого медленного типа связи, веба, стандартом стал самый длинный формат передачи данных — XML и его призводные: SOUP и т.п. и т.д. Получилось «медленно в квадрате»,dyadyaSerezha
19.06.2015 17:14-1 вместо внятного объяснения? Так держать.
Antelle
19.06.2015 17:31+6Я не минусил, но попробую объяснить. Апплеты, флэш, сервелат,… предлагалют браузер внутри браузера. Оно бажное, небезопасное, плохо адаптированное к операционке пользователя, проприетарное и избыточное. Всё для работы с UI уже есть, зачем ещё это? Нам не нужна отдельная библиотека контролов вместо DOM. Нам нужна возможность написания кросс-платформенной логики, а желательно ещё и производительность.
Вобщем-то это и есть развитие идеи компилированного кода из апплетов, но «обезжиренное», избавленное от UI и нестандартизованного проприетарного API.dyadyaSerezha
19.06.2015 19:29Про Флэш понятно, это полностью свой фреймворк со своим GUI.
Сервелат — это сервлеты? Они вроде как вообще не про это и испоняются на сервере.
Теперь к апплетам. Если у апплетов и есть своя GUI-библиотека (от Java), то она явно не проприетарная, а очень даже стандартная и кроссплатформенная, как и сама Java. Но что мешает писать на ней только логику?
DOM? Я всегда думал, что это стандарт иерархической структуры сложных документов, а также навигации/поиску по ней. Она уже и GUI-контролы включает?
Еще раз: казалось бы, уж что есть еще более кроссплатформенное, чем Java? Хотя сами исходники закрыты, конечно…Antelle
19.06.2015 20:39+2Сервелат — silverlight (то же, что флэш, но Microsoft).
> уж что есть еще более кроссплатформенное, чем Java
На iOS её нет в принципе. На Windows нет предустановленной. Включать её в браузеры? Просить ставить отдельно (как было в апплетах) — моветон.
> она явно не проприетарная, а очень даже стандартная
Jav-у разрабатывает Oracle, а не коммитет из Microsoft+Google+Mozilla+Apple+ещё некоторых.
> DOM? Она уже и GUI-контролы включает?
Кнопочки, поля ввода, взаимодействие с ними ит.д. — всё это включает в себя DOM API, и позволять заменять его категорически не надо.
И получается — как же это развивать? Отобрать jav-у Оракла, выпилить UI, бОльшую часть стандартной библиотеки, оставить только VM (а зачем, когда есть свой)? По-моему, так проще взять уже имеющуюся JS VM и сделать компиляцию под неё.
forgotten
22.06.2015 09:28+3> она явно не проприетарная, а очень даже стандартная и кроссплатформенная
… а Оракл вовсе не судится с Гуглом за то, что гугл написал свою реализацию, да? И не пытается доказать в суде, что номенклатура классов и объектов языка защищается копирайтом?
bertmsk
19.06.2015 14:13-4До изобретения Явы осталось совсем чуть-чуть…
int19h
20.06.2015 02:14+5Это намного более низкоуровневая вещь, чем Java. В нее можно компилить C — попробуйте сделать это с JVM…
dbanet
22.06.2015 05:30+1В нее можно компилить C — попробуйте сделать это с JVM…
Да вы не поверите…
А человеку минусы поставили незаслуженно.
mediaton
19.06.2015 15:45-1Мне вот интересно, можно ли будет из нативного js прозрачно работать с кодом загруженным в этом формате? Например скомпилировать к примеру node.js, отдать клиенту и вызывать node.js api из js скрипта?
mediaton
20.06.2015 14:23Хм, может кажется это вполне возможно github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration
mediaton
20.06.2015 14:51точно, js как клей для скомпилированных библиотек это очень круто. github.com/WebAssembly/design/blob/master/FAQ.md#is-webassembly-trying-to-replace-javascript
PavelMSTU
19.06.2015 16:34Интересно,
а что с безопасностью?
Кто-нибудь посоветует работы, посвященные ИБ в WebAssembly?neolink
19.06.2015 16:42+3да только начали драфты стандарта делать, ещё мало материала который четко обрисовывает даже его принципы, какие работы по безопасности?!
почитайте про NaCl от Google там про выполнение ассемблерного кода скачанного с интернета на процессоре
DaylightIsBurning
19.06.2015 18:27Web-разработка на Qt? :) Запуск десктопных программ в браузере?!
Riateche
20.06.2015 02:14Уже реальность с emscripten-qt.
DaylightIsBurning
20.06.2015 13:23да, видел, но webassembly позволит выйти этой идее на новый уровень :)
csmile
19.06.2015 21:29-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, а дальше творите сами — бой покажет.
Master_Dante
22.06.2015 03:02Место HTML займет WPF уверен в этом. Получится тот же Silverlight только с черного входа, чтоб никто не заподозрил.
VolCh
22.06.2015 07:53+1Ни к HTML ни к CSS этот ray-tracer не пришьёшь.
DOM доступен точно, вероятно и CSSOM. Собственно, всё что доступно JS в браузере должно быть доступно и WA-коду.
likerRr
19.06.2015 21:33+1Ребята, я немного не понял. То есть теперь веб-приложения потенциально могут состоять из c++ \ c# \ go \ js кода одновременно? Как все это поддерживать? Возможна ли ситуация, когда над проектом будет работать несколько разработчиков и каждый будет писать на языке, который он знает, в итоге превратив код в кашу?
Antelle
19.06.2015 21:46+1Поддерживать так же, как сейчас emscripten (или нативные компоненты, скажем, в C#). То есть, некий модуль, который пишется на C++ (ну или что там будет), остальное на JavaScript. Теоретически-то возможно, а практически, это я не знаю, как в C# нативный код добавить — т.е. мимо архитектора сам по себе такое вот так просто не появится.
likerRr
19.06.2015 22:00-1С emscripten не работал, к сожалению, поэтому не знаю, как там все устроено. Пытаюсь разобраться в такой ситуации: веб-проект писался на C#, C++ и т.д. Ты приходишь устраиваться на работу, как JS разработчик. Сможешь ли ты поддерживать (редактировать, добавлять новый функционал) в модули, написанные на этих языках, зная только JS? Или же будущему веб разработчику нужно будет знать кучу языков?
csmile
19.06.2015 22:10Ну вот Angular2 пишется на TypeScript. Значит нужно будет знание TypeScript если захочется его исходники понять.
Да и как бы Angular сам по себе уже и не HTML/CSS/JS в чистом виде, а нечто уже другое — сам по себе другой язык как бы.likerRr
20.06.2015 00:33-1TypeScript ничто иное как синтаксический сахар над JS, это немного другое. К тому же у меня язык не повернется сравнить TS и тот же C++, это как минимум неуместно. Поймите, я не против веб технологий и того веб стека, который сейчас есть в вооружении у веб разработчика. Я всерьез обеспокоен приходом низкоуровневых ЯП в веб
Antelle
19.06.2015 22:12+1Я сейчас работаю над проектом с большим куском логики на emscripten (ради кроссплатформенности). Команда сишников пишет на C++, команда JS-на JS. Приходишь как JS-разрабочик — пишешь фронт-енд на JS. Функционал на C++, если совсем не знаешь языка (или не хочешь), поддерживать, конечно, не сможешь. Когда устраивался, сказал, что знаю и JS и C++, занимаюсь интеграцией этого дела, т.е. одновременно приходится писать и на JS и на C++, но по большей части на JS, на C++ в основном мелочи, обёртки, binding-и всякие итд.
likerRr
20.06.2015 00:27Сложилось довольно скептическое отношение к таким новшествам. Что будет с рынком труда, во что превратится веб-разработчик? Не хотелось бы внезапно (утрирую конечно) в вакансиях увидеть: требуется веб разработчик: уверенные знания js, c++, java, c# опыт от 5 лет. Ясно, что человеку, ушедшему в веб дев в наше время будет сложно переключиться на низкоуровневые языки (да и зачем? я не хочу, я веб-разработчик), чего не скажешь об обратном. По-моему порог вхождения и ур-ни з\п резко изменятся, что думаете?
areht
20.06.2015 03:48> По-моему порог вхождения и ур-ни з\п резко изменятся, что думаете?
Я думаю люди на «низкоуровневых» языках решают другие задачи и вашей зарплате изменения не грозят. Просто теперь в их вакансиях реже будет появляться «JS» рядом с «веб».
Antelle
20.06.2015 09:04+2Зачем требования знаний js, c++, java, go все вместе к одному человеку? Это трэш какой-то, а не проект, если всем занимается кто-то один. Если действительно оправдана такая сегментация — скорее всего, проект большой, с разными командами, у каждой из которых свой язык (например, сервер на java, клиент на js, логика на c++, тесты на go), и уже становится не так страшно. Максимум может понадобиться знание одного языка + другого на уровне «читаю профессионально литературу, говорю плохо». Т.е. пишет на JS, может выполнить простые задачи на C++ (или наоборот).
Насчёт сложности переключения на низкоуровневые языки и з/п — хороший веб-дев, который умеет написать быстрый код, и сейчас стоит недёшево, и обычно основы си знает. Скорее всего так и останется, массово это не нужно и требоваться не будет.
Beholder
20.06.2015 11:16-4Java-ненавистники активно минусуют упоминания о Java… А будет ведь по сути всё то же самое, только с отставанием на несколько лет. Жалуетесь, что в Java (и в JavaScript) есть уязвимости, позволяющие обойти «песочницу»? Так они и в этой технологии появятся, никуда не денешься. Не один год пройдёт пока всё закроют. Жалуетесь, что «тормозит»? Про JIT-компиляторы безнадёжно упоминать, не слышат. Так и эта технология будет поначалу тормозить. Жалуетесь, что JRE раздута по объёму? Так там смотрите сколько в стандартной библиотеке полезного. Так и в этой технологии — будет либо почти голый рантайм с минимумом библиотек (и пишите всё сами и подгружайте динамически), либо когда всё это обрастёт стандартными библиотеками — точно так же раздуется сам браузер. Жалуетесь, что Java подгрёб под себя Oracle (а ранее Sun)? А вы уверены, что комитет из не очень дружественных компаний будет лучше, а не как в басне про лебедя, рака и щуку?
VEG
20.06.2015 11:42+1WebAssembly будет значительно более низкоуровневой, чем байт-код Java. Если в Java байт-код оперирует вполне себе объектами, то в WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами. Не просто же так в качестве основного языка выбрали C/C++. Зато под WebAssembly можно будет собрать и Flash, и JVM, и Silverlight. И всё это будет выполняться в стандартной песочнице браузера. Разве не прекрасно? :)
Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java. Здесь уже несколько раз об этом упоминали, а любители Java продолжают писать те же глупости. Такое впечатление, что научились стучать молотком, и пытаетесь забивать им даже шурупы. И вообще непонятно, почему тогда уже не Flash или Silverlight? Flash, кстати, вполне себе позволяет выполнять код, скомпилированный из C++. И он очень популярен, есть на большинстве машин, в отличие от столь упоминаемой здесь Java. Но от него уже сколько лет пытаются избавиться. Всё потому, что это совершенно отдельная сущность, которая плохо интегрирована с браузером, и предлагает много лишнего.Beholder
20.06.2015 15:33-2Вы знаете, я ничего не писал про высокоуровневость или низкоуровневость. На что именно вы отвечаете? Ответьте уж лучше на те пункты, что были в моём комментарии.
И откуда вы так уверены, что там чего-то будет? Пока одни тольно намерения да мечты. В жизни всё разбивается о разные трудности.VEG
20.06.2015 15:43+3И откуда вы так уверены, что там чего-то будет? Пока одни тольно намерения да мечты. В жизни всё разбивается о разные трудности.
У Google уже есть PNaCl, у него уже есть опыт в разработке таких штук. Просто другие не поддержали его начинания, видимо из-за того что это разработка лишь одного игрока. А теперь гиганты объединились, и вместе они наверняка смогут сделать нечто достойное стандарта. Не объявляли бы о создании такого альянса, если бы не были уверены в том, что у них что-то получится. А если не получится — конечно, жаль, но от этого идея не станет хуже, и JVM от этого не станет привлекательнее.
Maccimo
21.06.2015 04:37+1>> WebAssembly будет значительно более низкоуровневой, чем байт-код Java.
Не вижу здесь никакой «большей низкоуровневости»: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/wasm-opcodes.h
Скорее даже с точность наоборот:
— Есть отдельные опкоды для Break и Continue, оба из которых на x86 будут скомпилированы в банальный безусловный переход.
— Зачем-то есть отдельные опкоды для IfThen и для Ternary (вероятно, это flag?foo:bar) с показательным комментарием «TODO(titzer): reduce duplication with kStmtIfThen.» вот здесь: https://github.com/WebAssembly/v8-native-prototype/blob/master/src/wasm/decoder.cc#L683
>> Полагаю, что минусы за безграмотность сравнения WebAssembly и байт-кода Java.
И там и там байткод, и там и там виртуальная машина.
Умеющий абстрактно мыслить да увидит аналогию.
>> WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами. Не просто же так в качестве основного языка выбрали C/C++.
Выбор C/C++ в качестве основного языка о наборе инструкций ничего не говорит.
Как вы и упомянули, под Flash Player тоже можно скомпилировать исходники на C/C++ и это при том, что набор инструкций AVM2 весьма высокоуровневый.
Хотя, замечу в скобках, что со временем там и добавили ряд инструкций специально для оптимизации такого кросс-компилированного кода.
>> Но от него уже сколько лет пытаются избавиться.
Кто пытается и отчего у него это до сих пор не получилось?VEG
21.06.2015 10:15+4Ну так код на C/C++ можно скомпилировать и в JavaScript. Только в нём нет адекватных подходящих инструкций для типичных операций для низкоуровневого кода типа работы с данными по указателю. Для того чтобы это как-то исправить, придумали asm.js, но получилось всё равно сильно громоздко. К слову, текущая экспериментальная реализация — это по сути asm.js, переведённый в двоичный формат.
Байт-код Java даже банально не то что указатели не поддерживает, там нет и простейших структур. Даже IL из .NET намного лучше годился бы для такой роли, потому что там разработчики изначально подумали над тем, чтобы предложить широкий набор способов оптимизации, не загоняя разработчиков в узкие рамки, и там целиком поддерживаются как полноценные структуры, так и указатели (но это с ограничениями, если не выходить за пределы управляемого кода).
То есть компиляцию из C++ в байт-код Java конечно можно сделать (как и в любой другой байт-код или язык), вопрос только в том, насколько он получится эффективным. Байт-код Java — неэффективен, потому что он оперирует только слишком высокоуровневыми объектами и не разрешает работать с сырой памятью, то есть при компиляции в байт-код Java мы вынуждены были бы использовать неэффективные структуры данных для имитации простейших и всегда используемых низкоуровневых операций. Костыль, однако. Говорить о том, что этот байт-код можно расширить и добавить нужное, не приходится. Вспомните какими костылями прицепили туда поддержку generics в погоне за C#/.NET IL :)
— Есть отдельные опкоды для Break и Continue, оба из которых на x86 будут скомпилированы в банальный безусловный переход.
Вот именно, что в этих инструкциях нет ничего высокоуровневого — они легко переносятся на любой машинный код без потерь в производительности даже при компиляции под какой-нибудь древний 6502, который ещё в Dendy стоял. В том же FASM подобные вещи легко реализуются на макросах, можно делать полноценные условия, циклы, вкладывать код и т.д. Выглядит это так:
— Зачем-то есть отдельные опкоды для IfThen и для Ternary
Стал ли от этого ассемблер высокоуровневым? Нет, это всего-то макросы, которые генерируют простой код без накладных расходов — руками вы бы написали похожий на сгенерированный этими макросами код. Причём, если вам не нравится что-то в этих макросах — вы можете их изменить. Это я к тому, что эти макросы условий и т.д. не встроены в FASM, а реализованы на его макро-языке. Если что-то легко реализуется на простых макросах, эта реализация практически не имеет накладных расходов (то есть руками вы бы написали примерно то же самое) — значит, это достаточно низкоуровневая вещь..if eax<=100 & ( ecx | edx ) inc ebx .endif
Формат у WebAssembly будет не просто линейным набором команд. Там будет готовое к употреблению AST, что сделано для возможности однозначного перевода двоичного формата в текстовый и обратно в двоичный. Но набор то инструкций всё равно создаётся с расчётом на компиляцию из языков типа C/C++, а значит он будет изначально рассчитан для эффективного представления типичных низкоуровневых операций. И то что там условия и циклы будут похожи на макросы FASM ничего не меняет. Все эти плюшки легко и без накладных расходов переводятся в машинный код для любого процессора.
Кто пытается и отчего у него это до сих пор не получилось?
Разработчики браузеров? На мобильных платформах с поддержкой уже совсем плохо. На десктопе ещё держится, но пропаганда отказа от Flash не прекращается. А почему его до сих пор используют — это вопрос не ко мне. Я не использую, на некоторых компьютерах, чтобы не возиться с убогим обновлятором Flash, просто отключаю его совсем. Например, мои родители полгода назад начали жаловаться, что youtube перестал работать. Оказалось, что Firefox заблокировал Flash и стал требовать активировать его отдельно для каждой страницы, поскольку его версия устарела. Чтобы не объяснять им процедуру обновления Flash (который почему-то не научился делать это полностью автоматически), я его просто отключил целиком и всё стало хорошо. Аудитория у мобильных ОС уже очень большая, и все основные поставщики контента вынуждены реализовать нормальную работу и без Flash. Так что процесс идёт.
VEG
20.06.2015 15:35+2А будет ведь по сути всё то же самое, только с отставанием на несколько лет.
Это не то же самое. Все пункты что вы написали автоматически становятся бессмысленными, если понять это. Я думал, это будет очевидно из моего комментария.Beholder
20.06.2015 15:44-1Не очевидно. Кому очевидно? Слёту сказать «очевидно» — это демагогический приём.
VEG
20.06.2015 16:03+2Вы сказали:
А будет ведь по сути всё то же самое, только с отставанием на несколько лет.
На что я ответил:WebAssembly будет значительно более низкоуровневой, чем байт-код Java. Если в Java байт-код оперирует вполне себе объектами, то в WebAssembly всё будет близко к быстрому машинному коду, с указателями и тому подобными вещами.
Я указал на существенное различие. Извините, я не знал, что нужно обязательно в конце добавить «вывод: это не одно и то же».
Вспомнилось, как лет 10-15 назад учителя оценку снижали за отсутствие вывода в лабах :)
schetchik
21.06.2015 00:08+2Забавно, одна и та же новость привела к двум противоположным выводам:
1) JS умрет
2) JS все зохавает
:)
VitaminPSG
21.06.2015 11:58Интересно, а можно ли будет в хроме вставлять cpp код, что бы тестить скрипты на лету?
Finom
22.06.2015 01:18-2Я как и все рад, что программы будут исполняться быстрее. Но для браузерного веба этот прирост скорости будет незаметен. DOM по прежнему останется медленной задницой.
Master_Dante
22.06.2015 01:23По сути это идея платформы .net там тоже assembly и несколько языков. Давно пора имхо. А вот шутку с C\C++ я не заценил, писать юзер интерфейс на С это уже слишком.
VolCh
22.06.2015 08:59Можете писать на чём угодно и никто WA использовать для интерфейсов не обязывает. Один из стандартных юзкейсов — ядро скомпилировано под WA, интерфейс — обычный HTML/CSS/JS. Общаются между собой прозрачно синхронными вызовами в обе стороны. Ну и логично после C/C++ первым ожидать компилятор JS для WA — многие заинтересованы увеличить быстродействие без переписывания кода.
fogone
22.06.2015 10:10+1Посмотрите здесь и поймёте, что никто не собирается заставлять разработчиков писать ui на c++, стандарт предназначен для работы в браузере тяжелых задач вроде игр, видео, возможно какого-то сложного программного обеспечения вроде кад-ов, виртуализация и тому подобные вещи. Плюс дает возможность компилировать в производительный машинный код и другие языки за счет промежуточного низкоуровневого байткода. Более того, джаваскрипт по прежнему будет основным языком для работы на странице — по большому счету, эта новость в первую очередь для тех кто раньше в вебе вообще не работал или пытался компилироваться в asm.js.
DjOnline
24.06.2015 12:04Youtube сможет наконец сжимать видео в браузере перед отправкой, фотохостинги — сжимать изображение нужны алгоритмом (а не тем что в canvas) перед заливкой. В прочем, последнее делалось через flash/silverlight/java, но кого это волнует.
edinorog
Главный спонсор данного проекта почему-то не указан. Догадываюсь что это АНБ.
denis_g
Вам надо новый libastral скачать, ваша версия устарела.