и почему он не заменил Javascript… пока

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

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

История Всемирной паутины

Всемирная паутина, какой мы ее знаем сегодня, начиналась как одностраничный проект на компьютере NeXT в ЦЕРНе. Вы все еще можете просмотреть его здесь. Страница представляла собой простую статическую страницу, написанную на HTML и содержащую ссылки на проект и несколько других технических деталей. Мотивация этого проекта заключалась в том, чтобы обеспечить обмен информацией между учеными через сеть обмена документами.

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

Введите.. JavaScript

Созданный в 1995 году с целью извлечь выгоду из широкого распространения Java, JavaScript имел очень низкий барьер для входа. Это означало, что даже тот, кто не разбирался в технических вопросах, мог использовать его для добавления интерактивности на свою веб-страницу. Это способствовало его известности и росту в качестве де-факто цели компиляции по сравнению с конкурентами, такими как ActiveX, Adobe Flash, JavaBeans и т. д.

Но с этим безудержным подъемом возникло и несколько проблем. JavaScript — это интерпретируемый язык. Проще говоря, написанные вами функции объединяются и минимизируются в исходный файл. Отправляемый в виде простого текста в браузер Клиента, он должен быть проанализирован в Абстрактные синтаксические деревья, скомпилирован в байт-код и затем выполнен интерпретатором. Затем JavaScript-движок браузера обнаруживает любые потенциальные оптимизации с помощью таких методов, как JIT-компиляция, позволяющая в конечном итоге оптимизировать. Ключевое слово здесь в конечном итоге, так как это длительный процесс со скоростью в качестве конечной цели.

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

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

asm.js

Представленная как подмножество JavaScript, спецификация asm.js нацелена на описание изолированной виртуальной машины для небезопасных для памяти языков, таких как C или C++, и предоставляет низкоуровневый эффективный целевой язык для компиляторов. Впервые реализованная в браузере Mozilla Firefox, эта спецификация ввела улучшения производительности за счет использования заблаговременной оптимизации стратегии компиляции для действительного кода asm.js механизмами JavaScript.

Цитируя Документы Mozilla,

Это очень маленькое строгое подмножество JavaScript, которое допускает только такие вещи, как «пока», «если», числа, именованные функции верхнего уровня и другие простые конструкции. Он не позволяет использовать объекты, строки, замыкания и вообще все, что требует выделения кучи. Код Asm.js во многом напоминает C, но по-прежнему полностью действующий JavaScript, который будет работать во всех современных движках.

Хотя asm.js был улучшением с точки зрения производительности, он по-прежнему ограничивался вещами, которые можно было выразить в JavaScript. Поскольку это неформальная спецификация JavaScript, а не фактический стандарт, каждый производитель оптимизировал его так, как считал нужным. Хотя это и привело к конечной конвергенции, в отношении стандартизации определенно были возможности для улучшения.

Введите… Веб-сборка

Основываясь на опыте asm.js, все основные браузеры работали над созданием нового формата для Интернета, одной из конечных целей которого была скорость и эффективность.

WebAssembly, сокращенно Wasm, был разработан как переносимая цель компиляции для языков программирования, позволяющая развертывать в Интернете клиентские и серверные приложения.

Так что же такое WebAssembly? Это двоичный формат инструкций для машин на основе стека. Вот фрагмент того, как выглядит простая программа Hello world в Wasm.

Как видно из приведенного выше фрагмента, это ближе к машинному коду, чем asm.js или JavaScript. Следовательно, декодирование, компиляция, выборка и оптимизация кода WebAssembly занимает меньше времени. Почему?

Типичное количество времени, которое сегодня требуется движку JavaScript при запуске приложения, показано ниже.

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

Сравните это с тем, как выглядит типичный поток WebAssembly.

Существует не только заметная разница в количестве затрачиваемого времени из-за того, что он ближе к машинному коду, но и полное исключение некоторых шагов. Это, очевидно, приводит к лучшей производительности по сравнению с большинством случаев, но не во всех, поскольку WebAssembly все еще находится на начальной стадии (MVP был завершен в 2017 году).

Но подождите... значит ли это, что разработчики теперь должны будут писать целые кодовые базы на WebAssembly вместо JavaScript? Поскольку это похожее сравнение, очевидным ответом на этот вопрос было бы «да». Но это не тот случай! Ожидается, что большинство разработчиков Wasm будут продолжать кодировать на таких языках, как Rust, C и т. д., а затем компилировать в WebAssembly, чтобы пользователи могли воспользоваться преимуществами его производительности.

Так что это все для этого поста! Вот список ресурсов, которые помогли мне в процессе обучения,

Чтобы быть в курсе моих последних технических махинаций, подписывайтесь на меня в Twitter и LinkedIn.