«Заменит ли WebAssembly JavaScript на 20XX?» Это одна из тех «сенсационных» новостей на данный момент, верно? Но все же: если бы мы провели сравнение производительности WebAssembly и JavaScript, какой из них был бы победителем?

И получим ли мы одного и того же победителя для разных реализаций?

Мы все с нетерпением ждем будущего веб-разработки сейчас, когда WebAssembly «соблазняет» нас производительностью, близкой к нативной для браузера.

Тем не менее, большинство из нас по-прежнему пишут код на JavaScript, несмотря на предсказания его «неминуемого исчезновения». И все же есть случаи, когда JS превосходит WASM.

Итак, давайте выясним:

  • именно тогда, когда JavaScript работает лучше, чем WebAssembly
  • как работает WebAssembly и почему он так хорошо подходит для Интернета
  • действительно ли WASM быстрее JavaScript и когда именно

1. Расцвет WebAssembly: первая альтернатива JS для веб-разработки

Просто подумай об этом:

У нас был JavaScript в качестве единственного языка программирования, который будет использоваться изначально в веб-браузерах, а затем… вмешалась WebAssembly.

«Но что такое WebAssembly, точнее?». Действительно ли это язык ассемблера, как следует из его названия? Что ж, вот, надеюсь, достаточно ясное определение, над которым вы можете задуматься:

WASM - это новый тип кода с небольшим быстрым двоичным форматом для современных браузеров. «Цель компиляции», если хотите.

Тот, который вы можете использовать для компиляции любого языка программирования (включая JS).

И НЕТ:

Это не язык ассемблера, он не предназначен для конкретной машины.

И нет, вы не пишете код на WebAssembly: вы используете его для компиляции любого заданного языка.

Что он делает, так это компилирует языки более высокого уровня, а затем запускает эти веб-приложения в браузере намного быстрее, чем JavaScript (из-за его легкого низкоуровневого двоичного формата, помните?)

2. WebAssembly против JavaScript: существенные различия

Теперь, когда мы узнали, что такое WebAssembly, а что нет, позвольте мне кратко описать ключевые особенности, которые отличают наших двух «участников»:

JavaScript:

  • это динамически типизировано
  • это очень гибкий
  • он представлен в удобочитаемом коде

WebAssembly:

  • это просто быстро (э-э)
  • доставляется в небольшом двоичном формате
  • это строго типизировано

3. Как работает WebAssembly? Что скрывается за его «производительностью, близкой к родной»?

«Почему WebAssembly быстрее? Как это работает? »

Вот как работает WASM:

  1. вы, разработчик, пишете код для своего веб-приложения (на любом языке программирования)
  2. затем вы компилируете его в байт-код WebAssembly
  3. затем этот код запускается в веб-браузере, где он превращается в собственный машинный код и… выполняется.

И он загружается, анализируется и выполняется намного быстрее по сравнению с JavaScript.

Почему?

Поскольку его двоичные файлы легче текстовых файлов JS и, следовательно, их быстрее декодируют…

4. 3 сценария использования WebAssembly, повышающих производительность

Прежде чем я проведу «поучительное» сравнение производительности WebAssembly и JavaScript, позвольте мне выделить примеры использования, в которых WASM «сияет безупречно» в качестве «ускорителя веб-производительности».

Прежде всего, когда вы говорите «распространенные варианты использования WebAssembly», подумайте обо всех этих случаях, критичных к производительности:

  • редактирование видео
  • 3D рендеринг
  • видеоигры
  • потоковая передача музыки
  • шифрование
  • распознавание изображений

WebAssembly создан как цель для написания программного обеспечения в браузере.

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

А теперь уточним:

  1. перенос настольного приложения в Интернет: WebAssembly поддерживает те сценарии, которые выходят за рамки графического интерфейса, предоставляемого через HTML.
  2. уже существующий высокопроизводительный код на целевом языке: разверните его как модуль WebAssembly; здесь вы можете сохранить менее критичные к производительности элементы в JavaScript
  3. высокопроизводительный код, который нужно писать с нуля: очевидно, что asm.js не подходит

Короче:

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

5. WebAssembly против JavaScript: сравнение производительности

Теперь, когда мы выяснили, что WebAssembly обычно быстрее, чем JS, давайте:

  • узнать когда именно. Когда WASM превосходит JS?
  • подробнее изучить набор функций, которые позволяют WebAssembly работать лучше.
  • узнать обо всех тех случаях, когда JS нельзя «свергнуть»

5.1. Бинарные файлы WebAssembly быстрее загружаются и выполняются.

«Почему?» Потому что они меньше текстовых файлов JS.

Для сравнения, JavaScript должен:

  • разбирать
  • компилировать
  • оптимизировать

… Код перед его выполнением в браузере.

Хотя это:

  • легко написать
  • не требует предварительной компиляции (это язык с динамической типизацией)

… JavaScript по-прежнему требуется больше времени для выполнения всей необходимой работы перед выполнением кода.

5.2. С WebAssembly памятью можно управлять вручную

Другими словами: нет скопления мусора, который мог бы повлиять на производительность.

5.3. WebAssembly сокращает время начальной загрузки

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

Вот почему он декодирует намного быстрее, чем JavaScript:

  1. он имеет двоичный формат
  2. он статически типизирован (не нужно «угадывать», какие типы следует использовать)
  3. он заранее выполняет свою работу по оптимизации при компиляции исходного кода

Для сравнения, JavaScript должен:

  1. сначала превратите текст в структуру данных (или «абстрактное синтаксическое дерево» или AST)
  2. затем превратите этот AST в двоичный формат

Подумайте о веб-приложениях с большим количеством JS, стремящихся своевременно проанализировать все эти данные.

Доказано, что WebAssembly в 3 раза лучше во время загрузки.

5.4. JavaScript лучше работает с меньшими размерами массивов

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

5.5. Файлы WebAssmebly загружаются быстрее после попадания в кеш

В тот момент, когда они сохраняются в кеше браузера, файлы WASM загружаются легче, чем исходный код JS.

5.6. JavaScript часто лучше работает во время выполнения

После полной оптимизации WebAssembly работает медленнее при выполнении кода в браузере.

И это отчасти «вина» (некоторых) браузеров:

Например, в Microsoft Edge WebAssembly выполняется очень медленно.

5.7. WebAssembly на самом деле не «затмевает» JS с точки зрения производительности во время выполнения.

6. Что дальше? Станет ли WebAssembly чем-то большим, чем просто веб-решение?

Что ж, это цель, по крайней мере:

Чтобы выйти за рамки обычного использования в веб-браузерах.

Чтобы обновить его с веб-решения до варианта перехода для:

  • настольные приложения
  • мобильные приложения
  • другие среды исполнения

Более того, один из «прогнозов» состоит в том, что мы больше не будем говорить о соперничестве «WebAssembly vs JavaScript» в будущем, а будем говорить о сожительстве двух:

Вы по-прежнему сможете писать свой код на JavaScript, используя скорость, которую обеспечивает WebAsssembly: улучшенные фреймворки и библиотеки.

«Заменит ли WebAssembly JavaScript на 20XX?»

Я уверен, что это не так: JS по-прежнему является удобным и быстрым выбором для слишком большого количества задач.

Тем не менее, мы станем свидетелями успешного сотрудничества 2.

Статья изначально опубликована на OPTASY.com.