«Заменит ли 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:
- вы, разработчик, пишете код для своего веб-приложения (на любом языке программирования)
- затем вы компилируете его в байт-код WebAssembly
- затем этот код запускается в веб-браузере, где он превращается в собственный машинный код и… выполняется.
И он загружается, анализируется и выполняется намного быстрее по сравнению с JavaScript.
Почему?
Поскольку его двоичные файлы легче текстовых файлов JS и, следовательно, их быстрее декодируют…
4. 3 сценария использования WebAssembly, повышающих производительность
Прежде чем я проведу «поучительное» сравнение производительности WebAssembly и JavaScript, позвольте мне выделить примеры использования, в которых WASM «сияет безупречно» в качестве «ускорителя веб-производительности».
Прежде всего, когда вы говорите «распространенные варианты использования WebAssembly», подумайте обо всех этих случаях, критичных к производительности:
- редактирование видео
- 3D рендеринг
- видеоигры
- потоковая передача музыки
- шифрование
- распознавание изображений
WebAssembly создан как цель для написания программного обеспечения в браузере.
Вкратце: подумайте обо всех тех случаях, когда JavaScript обычно не может достичь необходимого уровня производительности.
А теперь уточним:
- перенос настольного приложения в Интернет: WebAssembly поддерживает те сценарии, которые выходят за рамки графического интерфейса, предоставляемого через HTML.
- уже существующий высокопроизводительный код на целевом языке: разверните его как модуль WebAssembly; здесь вы можете сохранить менее критичные к производительности элементы в JavaScript
- высокопроизводительный код, который нужно писать с нуля: очевидно, что 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:
- он имеет двоичный формат
- он статически типизирован (не нужно «угадывать», какие типы следует использовать)
- он заранее выполняет свою работу по оптимизации при компиляции исходного кода
Для сравнения, JavaScript должен:
- сначала превратите текст в структуру данных (или «абстрактное синтаксическое дерево» или AST)
- затем превратите этот 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.