Возможности и перспективы WebAssembly

Примечание. Не стоит негативно воспринимать критику автора  —  она исходит из восхищения возможным будущим WebAssembly и желания внести вклад в его реализацию.

У WebAssembly огромный потенциал, но этот язык программирования не получит значимого распространения, пока его использование будет ограничено нишевыми задачами. Самое время обратиться к DOM.

Возможности

WebAssembly (Wasm)  —  одна из важнейших разработок для веб-сферы со времен таких меняющих парадигму включений, как ajax-запросы.

WebAssembly был представлен почти 10 лет. Он описывался как решение множества веб-проблем, и я с нетерпением следил за его развитием, ожидая того дня, когда смогу его использовать.

Больше никаких транспайлеров

Одна из проблем, которую решил WebAssembly,  —  компиляция кода в код (транспиляция), широко используемая разработчиками веб-приложений.

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

       Исходный код 
            ↓
  Сборщик модулей + Babel + Terser
            ↓
 Уменьшенный нечитаемый JavaScript

WebAssembly предложил возможность использовать более эффективный байт-код в качестве решения целевой задачи компиляции в подобных случаях. Это позволило создавать более компактные “пакеты” с возможностью быстрого парсинга. 

     Исходный код Source
           ↓
 Компилятор WASM JavaScript 
           ↓
"Крошечный" бинарный WASM-файл  

Мультиязычность

Сейчас многие языки можно преобразовывать в Web с помощью методов транспиляции кода в код.

Существует компилятор Go в JavaScript, а такие популярные языки, как TypeScript, CoffeeScript и ClojureScript, преобразуют свой исходный код в JavaScript. Этот подход работает, но оставляет желать лучшего.

Некоторые языки отличаются специфическими особенностями, которые не могут быть эмулированы в преобразованном JavaScript (например, параллелизм в Go). В связи с этим возникает риск слабой поддержки сторонних библиотек.

Двоичный формат WebAssembly предлагает целевую задачу компиляции, не ограниченную языковыми особенностями JavaScript при использовании его в качестве целевого языка компиляции.

Поэтому хотелось бы дождаться того времени, когда разработчики WebAssembly предложат официальную поддержку этого языка как целевого языка компиляции.

Убийца JavaScript

Заявление о том, что WebAssembly не убьет JavaScript, по большей части соответствует действительности.

Если посмотреть на историю веб-технологий, то переход к веб-приложениям, в которых большая часть логики размещается на клиенте, не “убил” php и другие управляемые сервером технологии UI.

На самом деле десятки простых сайтов, разработанных на WordPress и им подобных, продолжают работать на JavaScript. И они никуда не денутся.

Если простой сайт, которому достаточно написать скрипт для открытия меню, не нуждается в сложном инструментарии, то успех более сложных приложений зависит от возможности выбора подходящих языков и профессионального уровня разработчиков.

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

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

Естественная эволюция

Поскольку веб-платформа  —  при всей ее доступности и прибыльности  —  отличается медлительностью в отношении инноваций, неизбежно возникли пользовательские библиотеки и фреймворки, такие как React и Angular. Они стремятся обойти ограничения платформы, предлагая разработчикам новые возможности и обеспечивая более удобное сопровождение баз кода.

Полизаполнение и прогрессивное улучшение доминируют, поскольку проекты, “изголодавшиеся” по новым функциям, пытаются достичь их как можно раньше.

Хотя это и не связано (напрямую) с WebAssembly, начали появляться приложения Electron/PhoneGap. Благодаря сочетанию относительно низкой стоимости разработки с межплатформенной переносимостью, они стали очевидным выбором, когда возникла потребность в широком использовании веб-приложений на Windows, MacOS, Linux, iOS и Android.

Сейчас появились веб-фреймворки на Rust и Go, ориентированные на WebAssembly, хоть для их функционирования и необходимо реализовывать огромное количество связующего кода.

В веб-пространстве стала прослеживаться закономерность: медленное развитие при высоких требованиях к качеству (и экономичности) ведет к тому, что многие проекты создают непрофессиональные реализации любыми доступными средствами.

JavaScript как языковой микс

Интересно наблюдать, как растущая потребность проектов в развитии веб-сферы в сочетании с тем фактом, что команды разработчиков не могут привнести собственные стеки, привело к тому, что стандарт ES (ECMAScript) стал языком, представляющим фрагменты из всех основных языков.

WebAssembly являет собой коренной поворот в этом отношении.

• Если компания, предпочитающая функциональное программирование, использует полноценный Closure или F#, ей неважно, реализует ли ES оператор pipe.
• Если компания, предпочитающая объектно-ориентированное программирование, использует Java, C# и Kotlin, ей безразлично, реализует ли ES декораторы.

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

А как насчет рантаймов

Для выполнения кода приложения, наряду с двоичным форматом Wasm, должны быть предоставлены рантаймы (среды выполнения).

Есть множество стратегий для решения этой задачи. Одна из них  —  разделение кода в рантаймах, также известных как кэшируемые рантаймы с возможностью динамической связи. 

Другой подход заключается в написании приложений на языках, требующих минимального/отсутствия кода в рантайме, таких как Rust и TinyGo.

Переключение внимания с JavaScript на DOM и особенности платформы

Если предположить, что WebAssembly обладает теми же возможностями, что и JavaScript, то это дает разработчикам внешнего языка возможность развивать и поддерживать свой язык независимо от браузера, что снижает давление на разработчиков стандарта ES и разработчиков браузеров.

Хочется сказать, что развитие возможностей веб-платформы представляет большую ценность, чем развитие возможностей ES.

Предоставление по желанию пользователя доступа к функциональности ОС на нижнем уровне с использованием “песочницы”/безопасности сделает такие проекты, как Electron, ненужными, предложив пользователям более эффективные настольные веб-приложения. Такие проекты, как VSCode и Slack, действительно могут стать устанавливаемыми веб-приложениями, более оптимизированными благодаря совместному использованию одного и того же движка браузера, а не нового независимого процесса Electron.

Фокусирование на разработке усовершенствованных спецификаций для повышения уровня конфиденциальности с помощью таких возможностей, как постоянное хранение данных по желанию пользователя и эффективное создание скриптов сторонних разработчиков в “песочнице”,  —  более важный вклад, чем оператор pipe.

И поэтому кажется пустой тратой ресурсов то, что поставщики браузеров внедряют новые функции ES, хотя могли бы сосредоточиться на улучшении конфиденциальности и возможностей браузера.

На каком этапе развития находится WebAssembly

Критиковать такое прогрессивное явление, как WebAssembly,  —  дело несложное и неблагодарное. И все же самое время заняться следующим:

• определить, на каком этапе развития находится Wasm;
• попытаться увидеть его перспективы;
• подумать, как ускорить его прогресс.

Академический проект

Разработка WebAssembly представляет собой в основном научную деятельность. С таким подходом она достигла значительного прогресса.

Однако сегодняшние коммерческие приложения WebAssembly (включая проекты с личной вовлеченностью разработчиков) выглядят ограниченными и отягощенными сложностью интеграции.

Можно восхищаться такими библиотеками, как ffmpeg и библиотеки сжатия изображений, которые WebAssembly портирует в веб-пространство. Однако в повседневной практике веб-разработчики редко сталкиваются с ситуацией, когда нужно сжать/конвертировать видео/изображения в браузере так, чтобы это оправдало дополнительные сложности интеграции модуля Wasm (раньше я сжимал изображения перед загрузкой с помощью canvas).

В текущем виде WebAssembly  —  просто трудно интегрируемый Web Worker, который может быть написан на языках, отличных от JavaScript. За исключением отдельных случаев, Wasm представляет собой чистую потерю производительности приложения.

PR-проблема

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

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

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

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

• React был в альфа-версии и с тех пор продвинулся до версии 18.
• Vue был в альфа-версии и с тех пор достиг версии 3.
• Angular 2 был анонсирован и с тех пор продвинулся до версии 14.
• Выпущен первый стабильный релиз Rust (версия 1).
• Версия ядра Linux была 3.x.x, а в настоящее время  —  5.x.x.
• Версия Chrome была 30, а сейчас  —  103.
• Была анонсирована Windows 10 и выпущена Windows 11.
• Выпускался iPhone 6.
• MacBook с сенсорной панелью еще не появился.

Учитывая ценность Wasm, важно, чтобы проект начал развиваться и позволил создавать высокопроизводительные клиентские приложения.

Что можно сделать

Вклад в спецификацию Wasm требует довольно специфического набора навыков. И это может отбить желание участвовать в разработке его спецификацией у многих инженеров.

Однако вы можете приобщиться к развитию WebAssembly, не внося непосредственного вклада в его спецификации. Для начала определите, зачем он вам нужен, а затем постарайтесь привлечь инвестиции в этот проект.

Определите, зачем вам нужен Wasm

Важнейший вопрос заключается в том, для чего вы хотите использовать Web Assembly.

Он поможет перестроить и избавить от ограничений к отслеживанию изменений данных такие проекты, как Angular, Svelte и Vue, которые используют компиляторы для преобразования синтаксиса своих шаблонов в оптимизированные для AoT инструкции по DOM-манипулированию?

Он позволит взять строгое React-приложение TypeScript и, не внося изменений, перенести меньший двоичный файл, который будет быстрее и эффективнее?

Он даст возможность построить SPA на C++, Rust и Go и сделать его многопоточным?

Выясните, что он даст вашему продукту

Подумайте, нужен ли Web Assembly для существенного улучшения вашего продукта.

• Улучшит ли он производительность приложения, обеспечивая высокое качество клиентского опыта?
• Позволит ли повышение производительности распространять приложение на более широкий спектр устройств для увеличения аудитории потребителей?
• Позволит ли перспектива использования одного и того же языка на клиенте и сервере совместно использовать код/модели для повышения стабильности платформы?
• Позволит ли языковая однородность сосредоточить требования к найму на одном языке и лучше использовать существующие инженерные ресурсы?

Можете ли вы количественно, а главное  —  финансово  —  оценить улучшения, которые даст Web Assembly?

Жизнь проекта зависит от его участников. Поэтому важно, чтобы они были заинтересованы в возможностях, которые он предлагает.