Почему WebAssembly Framework – это будущее Интернета – CloudSavvy IT

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

Что такое WebAssembly?

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

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

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

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

AssemblyScript, версия TypeScript, скомпилированная в WASM

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

Даже традиционные языки рабочего стола, такие как C ++ и Rust, могут быть относительно легко скомпилированы до WASM; AutoDesk смог портировать свою 35-летнюю кодовую базу C / C ++ на WASM через несколько месяцев, и Google портировал Google Планета Земля, обе из которых визуализируют сложные 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 и как начать его использовать.

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

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

Вугу – это фреймворк, написанный на Go, поддерживает компоненты и смоделирован по синтаксису Vue, но все еще является экспериментальным. Есть также Vecty, который также является популярным фреймворком Go.

Будущее WebAssembly

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

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

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

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

– Соломон Хайкс (@solomonstre) 27 марта 2019 г.,

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

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

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