Как WebAssembly становится популярным как для внешнего, так и для внутреннего интерфейса
WebAssembly (WASM) стал модным словом в последние несколько лет. Это технология, которая привлекает много внимания, но менее широко используется на практике. Мне было любопытно его текущее состояние, поэтому я исследовал и обобщил свои выводы. Некоторые из них могут вас удивить.
Фон
Javascript был единственным языком программирования, поддерживаемым веб-браузерами, пока не вышел стандарт WebAssembly. Однако WASM никогда не создавался в качестве замены Javascript, да и не может быть, потому что язык очень низкоуровневый. Вместо этого он специально создан, чтобы дополнять Javascript и решать проблемы с производительностью при выполнении вычислений и задач, требующих большого объема памяти — редактирование видео, игры, САПР и т. д.
Но по мере его развития также включаются некоторые интересные и неожиданные сценарии побочных эффектов, как вы увидите в этой статье.
Несколько быстрых заметок, прежде чем мы двинемся дальше:
- Вы не пишете WASM напрямую. Вместо этого вы используете языки высокого уровня, такие как C++ или Rust, и компилируете в WASM.
- Он хранится в компактном двоичном формате (как машинный код).
- Он выполняется в безопасной изолированной песочнице.
- Сам по себе он мало что делает, кроме как быстро обрабатывает большие пакеты чисел. Нет ни сети, ни файловой системы, ни доступа к DOM.
То, что люди создают с помощью WebAssembly, можно разделить на две категории: в браузере и на сервере.
В браузере
Люди используют WebAssembly в браузерах в основном по трем причинам:
- Оптимизация производительности для вычислительных и ресурсоемких задач.
- Перенос устаревших нативных приложений в веб-приложения.
- Разрешить запуск языков, отличных от Javascript, в браузере.
Давайте рассмотрим несколько больших успехов для этих вариантов использования.
Фигма
Если вы UI/UX-дизайнер или разработчик, который время от времени портит свой дизайн, вы не могли пропустить Figma в прошлом году. Это фантастический продукт, демонстрирующий современную производительность веб-приложения, которое может быть сегодня.
WebAssembly — один из секретов успеха Figma. К удивлению многих, хотя редактор Figma и является веб-приложением, он написан на C++ еще до появления WebAssembly. Как это возможно, если браузеры выполняют только Javascript? Ответ прост; код C++ транспилируется в Javascript перед доставкой в Интернет.
Но почему не Javascript с самого начала? Принципиальное отличие заключается в том, как код C++ переносится в JS. Javascript — очень динамичный язык. Чтобы заставить его работать быстро, браузерные движки делают много волшебства, чтобы оптимизировать его на лету. Однако результат все равно неоптимален и непредсказуем. Есть способ повысить производительность с помощью Javascript — напишите код, больше похожий на то, как вы используете статические языки, чтобы движкам было легче его обрабатывать. Первоначально Figma использовала «asm.js» для достижения цели — по сути, это транспилятор, который эффективно превращает код C++ в код Javascript.
Однако, в конце концов, это все еще Javascript-код, он не компактен для загрузки по сети, и браузеру все равно нужно разобрать его текст. Здесь WebAssembly превосходит предыдущий подход. WASM — это машинно-ориентированный код. Он намного компактнее, чем Javascript, и требует гораздо меньших затрат на обработку браузером. Перейдя с asm.js на WebAssebmly, Figma получила трехкратный прирост производительности.
Автокад
Как продукт, созданный в 1982 году, AutoCad старше Интернета и чудовищен по размеру — он содержит колоссальные 15 миллионов строк кода на C++. Давно хотел перейти в веб, но переписывать все на Javascript просто нецелесообразно: много работы и гораздо более медленный конечный продукт. Наконец, WebAssembly пришел как спаситель.
Во многих отношениях использование WebAssembly в AutoCAD похоже на Figma, за исключением того, что у него была дополнительная проблема, связанная с жесткой зависимостью от ОС Windows. Тем не менее, по-прежнему удивительно видеть, что WebAssembly, как относительно новая технология, может поддерживать такое большое и сложное приложение и придавать ему свежий вид в современную эпоху.
Кстати, Adobe Photoshop тоже переехал в сеть с помощью WebAssembly.
Майкрософт Блазор
Blazor — это предложение Microsoft по разработке веб-интерфейса на основном языке бэкенда — C#, через WebAssembly. Как гласит его слоган, цель состоит в том, чтобы создавать полноценные веб-приложения без написания Javascript, но почему?
Мысль, вероятно, заключается в том, что разработчики Microsoft так любят C# и хотят использовать его везде.
// A Blazor component
@page "/counter"
<PageTitle>Counter</PageTitle>
<h1>Counter</h1>
<p>Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>
// C# below
@code {
private int currentCount = 0;
[Parameter]
public int IncrementAmount { get; set; } = 1;
private void IncrementCount()
{
currentCount += IncrementAmount;
}
}
Люди, которые были близки к экосистеме Microsoft, скорее всего, сразу же спросят: этот Silverlight возродился? Нет, это не так. Silverlight — это проприетарная технология, требующая установки и не поддерживаемая универсальными браузерами. Вместо этого Blazor основан на WebAssembly, который теперь является частью веб-стандарта.
Хотя его ценностное предложение немного странное, Blazor — отличная демонстрация потенциала WebAssembly по добавлению в браузер большего количества языков программирования. Я не думаю, что такие усилия могут угрожать доминированию Javascript, но могут быть интересные нишевые сценарии, где это очень полезно. Например, если Python работает непосредственно в вашем браузере, вы можете использовать блокнот Jupyter, не запуская локальный сервер Python:
На сервере
Создатели WebAssembly, вероятно, имели в виду возможность работы в небраузерных средах при создании технологии, но энтузиазм серверных разработчиков превзошел их ожидания.
Восторг понятен — WebAssembly предлагает идеальный способ выполнения ненадежного кода на сервере — он портативный, его легче защитить, он использует гораздо меньше памяти, чем JVM или Docker, и является естественной целью для компиляции многих высокоуровневых языков. Это может не иметь большого значения для длительных процессов веб-сервера, размещенных в вашем IDC, но может быть полезным для некоторых сценариев:
- Провайдеры бессерверного хостинга, которым необходимо выполнять краткосрочные процедуры для своих арендаторов в огромных масштабах, — быстрый старт, малая занимаемая площадь и песочница имеют решающее значение.
- Продукт SaaS, поддерживающий запуск подключаемых модулей, предоставляемых пользователями или сообществом.
- Пограничные среды, где ресурсы очень ограничены
Создание спецификации WASI положило начало расцвету серверного WASM. WASI — это равноправная спецификация WASM, целью которой является стандартизация того, как код WASM взаимодействует со средой размещения. В браузере в этом не было необходимости, потому что WASM является дополнением к Javascript, который уже имеет доступ к своей среде размещения (браузеру) через DOM, BOM и веб-API. На серверах WASM работает сам по себе, и он не очень полезен, если не может взаимодействовать со своей средой.
Если вас интересует реальный прогресс, ознакомьтесь со следующими компаниями, которые внедряют WASM на стороне сервера в сервисы.
По мере развития технологии они могут составить серьезную конкуренцию традиционным поставщикам PaaS/FaaS на основе контейнеров. Облачный бизнес уже давно жаждет небольшой, портативной, безопасной среды выполнения приложений.
Что дальше
WebAssembly все еще молодая технология. Со стороны браузера варианты использования надежны. Тем не менее, ему все еще нужно превратиться в более приятную для разработки вещь — сегодня вы не можете загружать WASM напрямую, как модуль ES, и для его интерфейса необходим сложный связующий код Javascript. На стороне сервера он еще более незрелый, и его значения спорны. Ожидается, что крупные игроки отрасли сделают на него ставку и ускорят его внедрение.
Будет интересно посмотреть, как WebAssembly раздвинет границы веб-разработки в 2023 году.
Want to Connect? I'm the creator of ZenStack, a toolkit that supercharges Prisma ORM with a powerful access control layer and unleashes its full potential for full-stack development. Our goal is to let you save time writing boilerplate code and focus on building what matters - the user experience.
