Поиск по сайту:

Почему фреймворки WebAssembly — это будущее Интернета

WebAssembly — это новый способ запуска кода в Интернете. С огромными технологическими компаниями, стоящими за ним, он готов произвести революцию в том, как мы пишем веб-приложения, но имеет свои особенности и ограничения. Являются ли фреймворки WASM жизнеспособными конкурентами библиотекам JavaScript, таким как React?

Что такое веб-сборка?

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

Магия WebAssembly заключается в том, что он достаточно низкоуровневый, поэтому на самом деле является простой целью компиляции. Любой достаточно быстрый язык должен в какой-то момент пройти через компилятор, даже JIT-компилируемые языки, такие как JavaScript, и обычно это означает компиляцию в машинный код x86 или ARM для работы на современных процессорах.

Однако вы также можете скомпилировать в другой формат; обычно это оказывается языком «более низкого уровня», который ближе к конечному машинному коду. Например, Java компилируется в байт-код Java, который отправляется в среду выполнения JVM, а C# компилируется в промежуточный язык Microsoft (MSIL), который отправляется в среду выполнения .NET. Вы даже можете «транспилировать» языки с одного языка высокого уровня на другой, чаще всего расширения, такие как TypeScript в JavaScript, но также и более странные, которых вы не ожидаете, например, Python в JavaScript, хотя это обычно грязно и содержит ошибки.

WASM — это просто промежуточный язык, который легко компилируется. На самом деле, это почти та же концепция, что и байт-код Java и MSIL C# — оба эти формата упрощают выполнение одного и того же кода на разных платформах, используя один и тот же формат, работающий в конкретных средах выполнения, созданных для каждой платформы.

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

Даже традиционные настольные языки, такие как C++ и Rust, можно относительно легко скомпилировать в WASM; AutoDesk смогла перенести свою 35-летнюю кодовую базу C/C++ на WASM за несколько месяцев, а Google перенесла Google Earth, обе из которых отображают сложные 3D-сцены и работают почти с родной производительностью. Игровой движок Unity также может работать в WASM.

В настоящее время WASM работает в 94% пользовательских браузеров, при этом поддержка IE, браузера UC и Opera Mini, как обычно, является главным сдерживающим фактором. Однако его поддерживают разработчики из Mozilla, Microsoft, Google и Apple, и его поддержка в современных браузерах быстро развивается. Как и большинство веб-стандартов, в настоящее время им управляет организация по стандартизации W3C.

JavaScript больше не единственный вариант

Отлично, так что это значит для всех? Что ж, хотя запуск DOOM 3 в веб-браузере — это, безусловно, крутая демонстрация, она не меняет правила игры.

До сих пор JavaScript был вашим единственным способом сделать ваши веб-страницы интерактивными. Любите вы его или ненавидите, он никогда не предназначался для использования так, как сегодня. Это был язык сценариев, предназначенный для выполнения тривиальных задач, таких как анимация выпадающих меню, и более 25 лет его собирали вместе для выполнения современных рабочих нагрузок. Только благодаря использованию самых современных движков JS и оптимизации JIT-компиляции его можно даже сравнить с нативными скоростями.

Итак, по мере того, как веб-страницы становились полноценными веб-приложениями, клиентские фреймворки JavaScript, такие как React, Vue и Angular, удовлетворяли спрос. Конечно, все еще существуют серверные фреймворки — вы читаете это в WordPress, PHP-фреймворке, — но клиентские фреймворки предлагают огромный прирост производительности. В клиентской среде модель DOM обновляется автоматически после нажатия кнопки или взаимодействия с приложением. Даже фреймворки, отображаемые сервером в реальном времени, должны сделать сетевой запрос, чтобы что-либо изменить, и в худшем случае должны обновить всю страницу.

Новшество, в котором действительно нуждается Интернет, — это достойные конкуренты таким фреймворкам, как React, написанные на языках, отличных от JavaScript.

В то время как весь внешний веб-код написан на JavaScript, внутренний код часто этого не делает. В высокопроизводительных рабочих нагрузках центра обработки данных часто бывает полезно использовать подходящие языки рабочего стола, такие как C#, C++, Rust и Go. В конце концов, они могут буквально сэкономить вам деньги, поскольку для удовлетворения того же спроса требуется меньше серверов.

Однако это также стоит вам денег во время разработки, поскольку теперь вам нужно иметь дело с совместимостью между вашим бэкэндом C # и вашим интерфейсом JavaScript. Просто невозможность совместного использования кода, моделей и библиотек может увеличить сложность разработки почти в 2 раза по сравнению с унифицированной системой. Только по этой причине серверные бэкенды NodeJS так популярны, несмотря на то, что 20 лет назад это казалось ужасной идеей.

Возможность писать код на C#, C++, Rust и Go, который работает на сервере и на клиенте, откроет двери для многих других возможностей и почти полностью устранит потребность в JavaScript как в языке программирования. В клиентской среде WASM Blazor использование JavaScript зарезервировано для взаимодействия с существующими клиентскими пакетами и базовыми сценариями.

Как работают клиентские платформы WASM?

Поскольку WebAssembly — это просто способ запуска кода в своего рода «среде WebAssembly», вы можете думать об этом как о запуске контейнера Docker. Например, среда Blazor от Microsoft (безусловно, самая популярная клиентская среда WASM) имеет два режима работы:

  • Blazor Server, который выполняет всю обработку и рендеринг на сервере и отправляет обновления в HTML DOM через WebSocket, и
  • Blazor WebAssembly, который делает то же самое, за исключением того, что теперь обработка и визуализация выполняются на клиенте через среду выполнения .NET, скомпилированную для WASM.

В последнем случае соединение WebSocket заменяется прямой ссылкой на DOM через JavaScript, поскольку WebAssembly в настоящее время не имеет возможности напрямую изменять DOM без вызова JS API. Вам также в любом случае понадобится JavaScript для «загрузки» приложения WASM, так что JS не исчезнет в ближайшее время.

Кроме того, клиентские фреймворки WASM в целом работают так же, как и любые другие фреймворки, а точные детали будут зависеть от реализации.

Например, Blazor сохраняет внутреннее состояние и запускает повторную визуализацию приложения при нажатии кнопки или вводе данных. Он создает новый HTML-код, используя код C#, работающий на WASM, а затем отправляет этот HTML-код в API-интерфейсы JavaScript для применения к модели DOM. Выполнение этого в WebAssembly снимает нагрузку с сервера и делает клиент быстрым и отзывчивым. Даже доступ к DOM через JavaScript немного медленнее, но все же намного быстрее, чем альтернативный доступ к DOM через Интернет.

Насколько быстрее мы говорим?

Вопрос «насколько быстрее WASM?» трудно определить. В целом это явно быстрее, в этом нет никаких сомнений, но в некоторых случаях это сложнее.

Доступ к DOM по-прежнему остается проблемой, поскольку он должен осуществляться через JavaScript, поэтому он будет таким же медленным, как и JavaScript. Однако это скоро будет исправлено. Иногда JavaScript может быть быстрее в определенных тестах, с которыми компилятор WASM может бороться, просто из-за того факта, что за плечами JS 25 лет итерации компилятора.

Для высокопроизводительных приложений, требующих большой вычислительной мощности, таких как игры и приложения, WASM обычно в 1,5–2 раза быстрее. Но это может быть та же скорость. Это также может быть на 20% медленнее, чем JavaScript. Это также может быть в 10 раз быстрее для некоторых функций. Существуют тесты, показывающие все эти результаты, поэтому единственное, что можно сказать наверняка, это то, что ваш пробег будет варьироваться.

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

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

Какие фреймворки работают прямо сейчас?

Самым важным из них на сегодняшний день является Blazor, разработанный Microsoft. Это первая клиентская среда WASM, поддерживаемая крупной компанией, и, вероятно, она станет катализатором того, что WASM наконец-то получит широкое распространение, которого он заслуживает.

Blazor WASM всего год, а Blazor Server был выпущен 3 года назад, но самое замечательное в Blazor то, что это просто расширение ASP.NET, 20-летней веб-инфраструктуры, которую Microsoft постоянно совершенствует. Вы можете использовать многие интерфейсные библиотеки, уже написанные для ASP.NET, и, вероятно, это будет единственная платформа, поддерживаемая менеджером веб-пакетов, конкурирующим с NPM.

Это не какой-то побочный проект — Microsoft продвигает Blazor как нечто большее, чем просто веб-фреймворк; это их следующая модель прикладного программирования. Они работают над Blazor Desktop, выпущенным в конце 2021 года, который работает так же, как Electron, для запуска тех же веб-приложений Blazor на рабочем столе. Они явно очень заботятся об этом, что является отличной новостью для WASM в целом.

Если вы хотите узнать больше, вы можете прочитать наши руководства о том, что такое Blazor и как начать его использовать.

Другой готовый к работе фреймворк — Yew, построенный на Rust, современном языке, похожем на C++, за исключением безопасности памяти из-за странного способа обработки ссылок. Yew работает быстро, поддерживает модель на основе компонентов, такую как React, и совместим с JS API.

asm-dom — это библиотека, написанная для C++, которая лишь подключает код C++ к DOM. Очевидно, что здесь вам нужно будет принести свою собственную инфраструктуру, но большинство разработчиков, достаточно сумасшедших, чтобы писать веб-приложения на C++, скорее всего, все равно будут это делать. Он также поддерживает откат к asm.js, ранней версии того, чем пытался стать WebAssembly. По сути, это подмножество JavaScript, ограниченное использованием только целых чисел (т. е. только байтов, а не объектов), что упрощает транспиляцию кода C++, так как это практически весь код C++, используемый в конце дня. Однако такая поддержка не очень полезна, так как очень мало сред, которые не будут поддерживать WASM, но будут поддерживать asm.js.

Vugu — это фреймворк, написанный на Go, поддерживающий компоненты и созданный по образцу синтаксиса Vue, но все еще являющийся экспериментальным. Есть также Vecty, популярный фреймворк для Go.

Будущее WebAssembly

Все это было сосредоточено на клиентских веб-фреймворках, использующих WASM для управления DOM и создания приложений. Но вы также можете просто портировать целые настольные приложения в Интернет. Это то, что делает Uno — использует WASM для запуска приложений универсальной платформы Windows (UWP) непосредственно в веб-контейнере, что также дает дополнительное преимущество полной кросс-платформенности. На самом деле немного странно, насколько хорошо это работает, и действительно похоже, что вы используете родное приложение Windows. Вы можете проверить это сами в их галерее.

В экосистеме WASM есть гораздо больше, чем просто это. Если вы хотите узнать больше, прочтите сборник awesome-wasm на GitHub, в котором перечислены несколько популярных проектов.

Наиболее заметным из них, о котором мы здесь не упомянули, является WASI — способ переносимого запуска WebAssembly в любой системе с использованием стандартизированного системного интерфейса. Поскольку WASM становится все более и более производительным, WASI может оказаться жизнеспособным способом запуска любого кода в любой системе, аналогично тому, как работает Docker, но без ограничений на ОС. На самом деле, Соломон Хайкс, создатель Docker, полностью поддержал его:

Если бы WASM+WASI существовал в 2008 году, нам не нужно было бы создавать Docker. Вот как это важно. Webassembly на сервере — это будущее вычислений. Недостающим звеном был стандартизированный системный интерфейс. Будем надеяться, что WASI справится с этой задачей! https://t.co/wnXQg4kwa4

— Соломон Хайкс/@shykes@hachyderm.io (@solomonstre) 27 марта 2019 г.

WebAssembly всего несколько лет. Ему еще есть куда расти, и он продолжает набирать скорость. Вполне разумно, что через пять лет такие фреймворки, как Blazor и Yew, будут так же распространены, как React, Angular и Vue.

Можно утверждать, что это фрагментирует веб-экосистему, но WASM является кроссплатформенным. WAPM, менеджер пакетов WASM, может стать удобным способом обмена библиотеками между фреймворками на разных языках.

В любом случае, веб-фреймворки, работающие на WebAssembly, имеют огромный потенциал, и Microsoft лично поддерживает один из них, и мы уверены, что за ними будущее Интернета.