От автора: этот вопрос на устах у многих разработчиков с тех пор, как WebAssembly (WASM) начал выглядеть так, как будто это может стать реальностью. Хотя многие предположили, что грядет замена JavaScript WASM, те, кто участвует в создании последнего, отрицают такое намерение.
В официальном FAQ на webassembly.org этот вопрос значится одним из первых — и ответ на него: «WebAssembly предназначен для дополнения, а не для замены JavaScript». Эксперты, такие как Брендон Эйх, бывший генеральный директор Mozilla, предсказывают будущее, в котором WebAssembly и JavaScript будут совместно развиваться.
Будущее веб-разработки
Хотя он может и не уничтожать JavaScript, WebAssembly, безусловно, изменит лицо front-end веб-разработки. Пока еще слишком рано говорить о том, как все изменится, но мы уже достаточно далеко продвинулись, чтобы делать некоторые прогнозы о будущем веб-разработки. Включение WebAssembly в будущее веб-разработки это:
Лингвистическое разнообразие
Чрезвычайно высокая скорость
Параллелизм
WebAssembly делает возможным лингвистическое разнообразие
WebAssembly значительно диверсифицирует языки, доступные для создания front-end приложений и инструментов, что позволит разработчикам создавать приложения на любом языке, который они захотят выбрать.
Уже существует впечатляющий список реализаций, с компиляцией WASM, поддерживаемой на более чем 20 разных языках, включая:
Rust
C/C++
C#/.Net
Java
Python
Elixir
Go
Такая диверсификация языков позволит развить веб-фреймворки для разработчиков этих языков, что в свою очередь даст им возможность разрабатывать приложения непосредственно на выбранных ними языках.
Некоторыми ранними примерами являются Yew для Rust и Humble в Go (Humble в настоящее время позиционирует GopherJS как «компиляцию на javascript», но я ожидаю, что скоро будет поддерживаться WASM back-end)
WebAssembly делает возможным создавать чрезвычайно быстрые веб-приложения
WASM позволит добиться довольно впечатляющего повышения производительности. Мы видели, как Firefox продемонстрировал, что в отличие от JavaScript, WASM может быть скомпилирован и выполнен так быстро, как это можно сделать в локальной сети.
Это улучшение времени парсинга устраняет одно из самых узких мест современных веб-приложенияй на JavaScript: время начальной загрузки. В наборе тестов, опубликованных Figma, средство проектирования на основе браузера при реализациях, использующих WebAssembly, показало 3-кратное уменьшение времени загрузки по сравнению с asm.js реализациями. Для больших документов это означало вместо более чем 10 секунд до первого взаимодействия всего менее чем 5. Это потрясающее улучшение.
Улучшение производительности во время выполнения было менее впечатляющим, но все же ощутимым. Контрольные показатели интенсивных графических операций для WASM по сравнению с D3 показали 30% улучшение у крупных проектов.
Даже если большое количество веб-приложений остается на JavaScript, библиотеки и фреймворки, созданные с помощью WebAssembly, могут позволить разработчикам воспользоваться этими улучшениями, и далее в основном полагаясь на JavaScript.
Уже есть доказательства того, что разработчики фреймворков исследуют эти возможности, а Ember.js рассматривает реализацию WASM для Glimmer VM. Я думаю, что эта тенденция будет развиваться все активнее. Представьте, что JavaScript-фреймворки отправляют «стартовые» последовательности, скомпилированные в WASM, которые постепенно расширяются с помощью JavaScript и загружают ваше приложение на основе JavaScript, позволяя сложным веб-приложениям загружаться и достигать первого взаимодействия так же быстро, как и простые статические веб-сайты.
WebAssembly сделает возможным параллелизм
Это, по общему признанию, более умозрительная тенденция, поскольку она не полностью реализован в сегодняшнем WebAssembly. С тех пор, как примерно в 2005 году начался переход к многоядерным процессорам, становится все более ясно, что для достижения большей производительности программное обеспечение должно стать параллельным.
В недавней презентации о будущем браузера Лин Кларк из Mozilla подчеркнул, что та часть веб-опыта, которую браузеры не могут «невидимо» параллелизировать, это фактический код приложения. JavaScript был разработан как однопоточный язык, а в то время как более новые инструменты, такие как Web Workers, допускают некоторый параллелизм в JavaScript, им все же сложно работать только на относительно ограниченном уровне курса.
Такие языки, как Rust и Go, были разработаны с учетом параллелизма с самого начала, что значительно облегчает написание параллельных приложений. Функция потоков WebAssembly по-прежнему остается лишь предложением, но как только она станет реальностью, мы сможем увидеть веб-приложения, использующие параллелизм на низком уровне.
В большей степени это опять же будет связано с уровнем фреймворков и библиотек. Я не предполагаю, что средний разработчик приложений использует потоки WebAssembly в своем приложении, но в рамках платформы существует огромный потенциал. Новая Fiber Architecture от React уже рассматривает возможность разделения внутренних процессов рендеринга, которые можно передавать и откладывать. Представьте, что Fibre на базе WebAssembly разбивает процессы рендеринга для всех доступных ядер, а затем просто передает их в приложение JavaScript по мере необходимости.
Яркое будущее веб-разработки
Не знаю, как вы, но я очень взволнован возможностями, предоставляемыми WebAssembly, даже если я никогда не буду иметь с ними дело напрямую и не буду кодировать на JavaScript. По мере того, как инструментарий продолжает развиваться, все больше браузеров используют возможности производительности, продемонстрированные Mozilla, а фреймворки и библиотеки все чаще используют новые функции, будущее веб-разработки выглядит очень ярким!
Источник: https://zendev.com/
Редакция: Команда webformyself.