Max Home IndustryWebAssembly был принят W3C и теперь является официальным веб-стандартом. Однако это не означает, что он готов к использованию.
Сага о WebAssembly, вероятно, озадачит программистов в ближайшие годы. У нас есть браузеры, которые имеют «родную» поддержку JavaScript, и это было усовершенствовано и эволюционировало на протяжении многих лет. Большинство программистов не любят JavaScript по целому ряду причин — он не элегантен, не основан на классах, слабо типизирован и работает медленно. Со временем также предпринимались попытки разрешить программистам писать на выбранном ими языке и запускать это в браузере. В то время как компиляция в JavaScript не делает ничего особенного для скорости, NaCl Google, который позволял компилировать программы в машинный код, позволял работать на полной скорости. Это казалось лучшей идеей, но никто не хотел отставать от Google в этом вопросе. Позже Google внедрил независимую от платформы версию NaCl , однако она больше не имела успеха в принятии.
Следующим предложением было изобрести подмножество JavaScript, которое можно было бы использовать в качестве языка ассемблера браузера- asm JS.Это сработало, но, возможно, не с той скоростью, на которую надеялись.
Последний подход состоял в том, чтобы подумать о реализации нового языка, который мог бы сосуществовать с JavaScript. Эта идея включала в себя совершенно новый язык низкого уровня, основанный на синтаксических деревьях. Преимущество языка, основанного на синтаксических деревьях, заключается в том, что он делает код быстрым для выполнения, и вы можете выбрать ряд архитектур для его реализации — например, машину стека, которая является медленной, но простой в реализации. Альтернативой было бы принять, скажем, виртуальную машину Java и воспользоваться преимуществами существующих компиляторов и инструментов. Я понимаю, почему веб-сообщество, возможно, не хотело использовать что-либо, связанное с подходом Oracle к Java, но есть альтернативы.
Вместо этого у нас есть совершенно новая экосистема, которая должна быть заполнена новыми инструментами, а на данный момент их не так много, и их трудно использовать. Очевидно, что пройдет еще некоторое время, прежде чем WebAssembly станет мейнстримом.
Чтобы было ясно — вы не собираетесь писать свой код в WebAssembly. Вы будете писать на Python, Julia, R или C и использовать компилятор для создания WebAssembly. Проблема в том, что на данный момент компиляторы и связанная с ними инфраструктура недостаточно развиты, чтобы вы могли нанять младшего программиста для выполнения этой работы. В конечном счете, он должен быть таким простым и отполированным, чтобы веб-сборка широко использовалась.
Еще одним интересным выбором является тот факт, что вы все еще не можете обойтись без JavaScript. Если вы ненавидите это, то привыкайте к мысли, что JavaScript по-прежнему является очень важной частью WebAssembly. Вам нужен JavaScript для маршалирования WebAssembly и общения с пользовательским интерфейсом. Решение на одном языке теперь невозможно, если вы хотите добиться максимальной производительности. Вам все равно придется писать существенные части любого приложения на JavaScript. Предполагается, что причина этого заключается в том, что использование JavaScript для обработки внешнего мира использует механизмы безопасности JavaScript. Это может вызвать пустой смех, поскольку JavaScript не только может быть подорван, добавление к нему WebAssembly делает вещи более сложными и, следовательно, более уязвимыми. Поверхность атаки только что была увеличена. Сложность-это друг вредоносных программ.
WebAssembly надеется встряхнуть не только браузер. Идея состоит в том, чтобы расширить стандарт, включив в него среды, в которых можно запускать WebAssembly. Поэтому я предполагаю, что идея состоит в том, чтобы сделать его жизнеспособной целью для каждого языка на планете, работающего на каждой платформе на планете. Мне это кажется маловероятным.
Я не могу не думать, что через несколько лет программисты будут рассматривать это как упущенную возможность. В WebAssembly есть много привлекательных вещей, но то, как он расширяет JavaScript и должен взаимодействовать с ним, нежелательно сложно.
Мы могли бы реализовать что-то совершенно новое и совершенно простое и позволить JavaScript сосуществовать или увядать в зависимости от воли мира.
Ян Эллиот является автором Just JavaScript: Идиоматический подход; Асинхронность JavaScript; Just jQuery: Основной пользовательский интерфейс и Just jQuery: События, Асинхронность и AJAX, которые являются частью библиотеки I Programmer, опубликованной I/O Press.