Примечание. Не стоит негативно воспринимать критику автора — она исходит из восхищения возможным будущим 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?
Жизнь проекта зависит от его участников. Поэтому важно, чтобы они были заинтересованы в возможностях, которые он предлагает.
Читайте также:
Читайте нас в Telegram, VK и Дзен
Перевод статьи David Alsh: Where is Web Assembly?
