Часто при разговоре о веб-разработке на ум приходят JavaScript и различные фреймворки. Но что, если бы веб-приложения могли запускаться с той же производительностью, что и нативные, а разработчики могли бы писать их на Rust, C++ или Go? Вот тут-то на сцену и выходит WebAssembly (Wasm) — инструмент, который позволяет взглянуть на веб-разработку иначе. Он открывает возможности для выполнения сложных вычислений, запуска игр, виртуальных машин и приложений для анализа данных прямо в браузере. Все это — с высокой производительностью и кроссплатформенностью, от настольных компьютеров до мобильных устройств.
В этой статье разберемся, как работает WebAssembly, чем он привлекает разработчиков и какие проблемы решает. Вы узнаете, почему его активно поддерживают такие компании, как Google, Unity и Unreal Engine, и какие перспективы открывает Wasm для будущего веб-разработки. Подробности под катом!
Используйте навигацию, если не хотите читать текст полностью:
→ Что такое WebAssembly
→ Почему WebAssembly вообще появился
→ Сравнение WebAssembly с JavaScript и объяснение их взаимодействия
→ Примеры использования
→ Как работает WebAssembly
→ Преимущества и ограничения WebAssembly
→ Будущее WebAssembly
Что такое WebAssembly
WebAssembly (Wasm) — это современный бинарный формат инструкций, предназначенный для выполнения кода в веб-браузерах с высокой производительностью. Он был разработан как универсальная целевая платформа для компиляции высокоуровневых языков программирования, таких как C, C++, Rust и других. Это позволяет запускать приложения на веб-страницах с почти нативной скоростью.
Wasm поддерживается всеми основными браузерами и позволяет разработчикам создавать сложные и ресурсоемкие приложения без необходимости использования JavaScript в качестве единственного языка программирования.
Что делает WebAssembly
- Ускоряет загрузку страниц за счет оптимизированной компиляции,
- Обрабатывает большие объемы данных в реальном времени без задержек,
- Поддерживает потоковую компиляцию, что позволяет начинать обработку данных до полной загрузки модуля
Почему WebAssembly вообще появился
Основная причина — стремление улучшить производительность веб-приложений. JavaScript хоть и является мощным инструментом для создания интерактивных интерфейсов, сталкивается с ограничениями в производительности при выполнении ресурсоемких задач.
Wasm позволяет использовать более эффективные языки программирования для выполнения таких задач, что значительно увеличивает скорость обработки данных и уменьшает время загрузки приложений. Например, приложения, написанные на C или Rust и скомпилированные в Wasm, могут работать в 2-3 раза быстрее, чем аналогичные решения на JavaScript.
Инструменты оценки производительности показывают, что Rust на 66 % быстрее JavaScript. Источник.
Сравнение WebAssembly с JavaScript и объяснение их взаимодействия
WebAssembly не заменяет JavaScript. Вместо этого он дополняет его. JavaScript остается основным языком для создания динамических пользовательских интерфейсов и управления состоянием приложений. Wasm же лучше подходит для выполнения вычислительно интенсивных задач, таких как обработка видео, физические симуляции и работа с большими объемами данных.
|
Параметр |
WebAssembly |
JavaScript |
| Производительность |
Почти нативная скорость |
Зависит от оптимизации движка |
| Языки |
C, C++, Rust и другие |
Только JavaScript |
| Использование |
Для тяжелых вычислений |
Для интерфейса и логики |
| Безопасность |
Более защищен от атак |
Уязвим к XSS и другим уязвимостям |
Примеры использования
WebAssembly активно применяется в различных отраслях, включая геймдев, SaaS-приложения и научные вычисления. Рассмотрим подробнее несколько конкретных примеров, подкрепленных актуальными данными.
Геймдев
WebAssembly значительно изменил подход к разработке браузерных игр. Инструмент обеспечивает высокую производительность и возможность запуска сложных игр без необходимости установки плагинов. Вот пара примеров.
Движок Unity поддерживает экспорт игр в формат WebAssembly, что позволяет разработчикам создавать игры, которые работают в браузере с производительностью, близкой к нативной. Например, игра AngryBots демонстрирует возможности движка в браузере с использованием WebGL и Wasm. В тестах игры на WebAssembly время выполнения тяжелых вычислений сократилось до 684 мс, что на 66% быстрее, чем при использовании JavaScript (две секунды).
Unreal Engine также поддерживает WebAssembly, позволяя разработать сложные 3D-игры. В 2024 году команда разработчиков Unreal Engine 5 представила улучшенную поддержку веб-платформы, включая поддержку WebGL 2.0 и WebGPU. Это позволяет динамически загружать данные и улучшает производительность игр в браузере.
SaaS-приложения
Одним из ярких примеров использования WebAssembly в SaaS-приложениях является Figma, популярный инструмент для дизайна интерфейсов. Переход на WebAssembly позволил Figma сократить время загрузки приложения более чем в три раза.
По данным тестирования, время инициализации приложения снизилось до 504 мс при использовании Wasm SQLite для хранения данных. Это значительно быстрее по сравнению с традиционными методами хранения информации.
Научные вычисления и симуляции
WebAssembly также находит применение в научных вычислениях. Например, NASA использует Wasm для создания симуляционных инструментов, которые позволяют исследовать автономные системы для удаленной работы.
Центр NASA CCMC (Community Coordinated Modeling Center) использует модели и вычислительные ресурсы для моделирования космической погоды и других научных задач. CCMC предоставляет доступ к более чем 60 уникальным моделям через онлайн-портал. Это позволяет исследователям по всему миру работать с данными и моделями без необходимости установки специального программного обеспечения.
Инструмент WebGS от NASA предназначен для визуализации многопользовательских симуляций беспилотных летательных аппаратов. Он позволяет взаимодействовать с реальными полетами и симулированными транспортными средствами в режиме реального времени, что делает его полезным для тестирования и разработки новых технологий управления воздушным движением.
Как работает WebAssembly
Рассмотрим базовую архитектуру, языки программирования, которые можно компилировать в Wasm, а также популярные инструменты и экосистему.
На что тратит время WebAssembly. Источник.
Базовая архитектура
WebAssembly использует компактный бинарный формат, который предназначен для эффективного выполнения на различных операционных системах и архитектурах. Это позволяет загружать и выполнять код быстрее по сравнению с текстовыми форматами, такими как JavaScript.
Wasm имеет фиксированный размер инструкций и упрощенную структуру, что позволяет ему загружаться и декодироваться быстро. Например, модули WebAssembly могут быть в 2-3 раза меньше по размеру по сравнению с эквивалентным JavaScript-кодом, что значительно ускоряет время загрузки.
Код на высокоуровневых языках, таких как C/C++, Rust и других, компилируется в WebAssembly байт-код. Этот процесс может осуществляться как заранее (AOT), так и во время выполнения (JIT). В современных браузерах используется JIT-компиляция для повышения производительности.
После загрузки модуль Wasm проходит проверку безопасности и компилируется в машинный код. Затем выполняется в изолированной среде (песочнице), что обеспечивает безопасность выполнения кода.
Какие языки можно компилировать в Wasm
На данный момент в WebAssembly можно компилировать более 40 языков программирования. Среди них:
- C/C++ (с помощью инструмента Emscripten),
- Rust (имеет встроенную поддержку для компиляции в Wasm через wasm-pack),
- C#/.NET (благодаря инструменту Blazor),
- Java (с помощью TeaVM и JWebAssembly),
- Python (поддержка Python еще находится на стадии разработки, но существуют проекты, такие как Pyodide, которые позволяют запускать Python-код в браузере через WebAssembly).
Инструменты и экосистема: краткий обзор популярных решений
Существует множество инструментов и библиотек для работы с WebAssembly. Рассмотрим наиболее популярные.
- Emscripten. Это мощный инструмент для компиляции C/C++ кода в WebAssembly. Он позволяет разработчикам использовать существующие библиотеки и кодовые базы для создания веб-приложений с высокой производительностью.
- Wasmtime. Это независимое исполняемое окружение для WebAssembly, которое поддерживает как JIT, так и AOT компиляцию. Wasmtime предлагает гибкость выбора движка компиляции и обеспечивает высокую производительность выполнения.
- WebAssembly Studio. Это онлайн IDE для разработки приложений на WebAssembly. Она позволяет пользователям писать код на различных языках (C/C++, Rust), компилировать его в Wasm и тестировать прямо в браузере.
- Binaryen. Это инструментальная инфраструктура для оптимизации WebAssembly кода. Он предоставляет различные оптимизационные проходы и инструменты для улучшения производительности приложений.
Преимущества и ограничения WebAssembly
Wasm становится все более популярным среди разработчиков благодаря своим многочисленным преимуществам. Давайте резюмируем их прежде чем перейдем к обзору ограничений.
- WebAssembly позволяет выполнять код почти с нативной скоростью. Это особенно важно для ресурсоемких приложений, таких как игры или графические редакторы. Например, тесты показывают, что приложения на Wasm могут быть до 20 раз быстрее JavaScript в некоторых сценариях обработки данных. В браузере Firefox WebAssembly выполняется в 2,4 раза быстрее, чем в Chrome, и в 8,7 раз быстрее, чем в Edge по сравнению с JavaScript в аналогичных условиях.
- Код, написанный для WebAssembly, может работать в любом современном браузере (Chrome, Firefox, Safari и Edge), что делает его универсальным решением для веб-разработки.
- WebAssembly позволяет компилировать код из популярных языков. Это открывает новые возможности для разработчиков, позволяя им использовать языки, с которыми они знакомы и которые лучше подходят для определенных задач.
- Код WebAssembly выполняется в песочнице, что обеспечивает дополнительный уровень безопасности. Это минимизирует риски уязвимостей при выполнении скриптов в браузере.
- WebAssembly и JavaScript могут взаимодействовать друг с другом. Это позволяет разработчикам использовать преимущества обоих языков: производительность Wasm для тяжелых вычислений и гибкость JavaScript для управления интерфейсом.
Несмотря на свои преимущества, WebAssembly также сталкивается с рядом ограничений. Одно из них — дебаггинг. Отладка кода на WebAssembly может быть сложнее по сравнению с JavaScript. Инструменты отладки еще не так развиты, поэтому может потребоваться больше времени и усилий для выявления ошибок в коде.
WebAssembly также не имеет (по крайней мере, пока) прямого доступа к объектной модели документа (DOM) браузера. Это означает, что придется использовать JavaScript для манипуляций DOM-элементами и взаимодействия с интерфейсом пользователя. А это может усложнить архитектуру приложения.
Хотя экосистема WebAssembly активно развивается, она все еще не так обширна, как экосистема того же JavaScript. Некоторые библиотеки и фреймворки могут не поддерживать Wasm или требовать дополнительных усилий для интеграции.
Наконец, модули WebAssembly могут увеличивать общий размер загружаемых файлов по сравнению с чистым JavaScript-кодом. Это может негативно сказаться на времени загрузки страницы.
Будущее WebAssembly
Wasm продолжает развиваться и открывает новые горизонты для разработки приложений. Рассмотрим, как он будет развиваться в ближайшие годы.
Как Wasm развивается и чего мы можем ожидать
В 2025 году WebAssembly ожидает ряд изменений. Одно из ключевых направлений — поддержка WASI (WebAssembly System Interface). Она позволит запускать Wasm вне браузера, включая серверные и облачные решения.
Ожидается, что WASI Preview 2 будет выпущен в ближайшее время. Это даст возможность использовать WebAssembly в более широком контексте, включая бессерверные архитектуры и контейнеризацию.
Также стоит отметить, что WebAssembly активно используется в области искусственного интеллекта. Например, Google Meet использовал Wasm для обработки размытия фона во время видеозвонков. В 2025 году многие ожидают расширения применения Wasm в AI-технологиях. Это позволит создавать более интерактивные приложения с использованием динамического контента.
Кроме того, внедрение сборки мусора и других новых функций, таких как многопоточность и доступ к графическим процессорам (GPU), значительно улучшит производительность и возможности WebAssembly. Это сделает Wasm более привлекательным для разработчиков, работающих с высокопроизводительными приложениями.
Прогнозы по внедрению в энтерпрайз и массовую разработку
Согласно текущим тенденциям, использование WebAssembly в энтерпрайз-секторе будет расти. Ожидается, что компании начнут активно внедрять Wasm для создания сложных корпоративных приложений благодаря его высокой производительности и кроссплатформенности. Например, уже сейчас многие организации используют Wasm для оптимизации своих веб-приложений и повышения скорости загрузки страниц.
Предполагается, что в 2025 году доля пользователей WebAssembly вырастет до 10-15% от общего числа пользователей браузеров. В настоящее время WebAssembly используется на более чем 3% сайтов в браузере Chrome, а с учетом других браузеров эта цифра будет выше. Также ожидается рост числа языков программирования, которые будут поддерживать компиляцию в Wasm.
С развитием экосистемы WebAssembly можно ожидать появления новых инструментов и библиотек, которые упростят разработку приложений на Wasm. Это позволит разработчикам быстрее интегрировать WebAssembly в свои проекты и использовать его преимущества без значительных затрат времени на обучение.
Комментарии (40)
rtatarinov
25.01.2025 14:21А что если вместо браузера изобретут что-то, что позволит открывать прям бинарники например! Так если призадуматься браузер здесь, как костыль. Все равно взаимодействие с ним писать на JS. Но такую систему никто не придумал вместо браузеров. Так что эта технология будет там использоваться где она реально нужна… для дорогих расчетов! Хотя это не факт. Условная figma так написана, если я не путаю. И последнее время она тормозит, как любое веб приложение, и жрет памяти, как не в себя….
Alexey2005
25.01.2025 14:21С учётом того, что Веб как таковой быстро теряет популярность, а весь контент уходит в мессенджеры, у WebAssembly на мой взгляд нет никакого будущего. Его как раз допилят к шапочному разбору, когда все будут сидеть по разного рода WeChat'ам с Discord'ами, через которые будет осуществляться всё - общение, просмотр контента, оплата сервисов...
GiveMeFreeNickName
25.01.2025 14:21Веб приложения, например фигму, вы в дискорде не запустите, с популярностью веба ничего не случится, вы кажется забыли что интернет это не только новости читать
CrashLogger
25.01.2025 14:21Все эти фигмы и дискорды гораздо лучше было бы писать на C++ или другом нормальном языке и компилировать в нативное приложение для соответствующей операционной системы, а не пытаться запихнуть в браузер то, для чего он не предназначен.
JerryI
25.01.2025 14:21С другой стороны фигма это почти по масштабам как ФШ, или иллюстратор. Они тоже кушают бывает много. Ну и команда их больше и времени у них на эволюцию было больше.
KirkaRo
25.01.2025 14:21как раз такая же мысль вертится, насчёт бинарников, но браузер пока что хороший костыль, ибо связывает все четыре основные
религииоперационные системы, по сути превращаясь в виртуальную машину.
mixsture
25.01.2025 14:21Я для себя отмечаю 2 огромных недостатка в этой технологии:
тяжелая среда исполнения. Для JS она уже встроена в любой браузер и время ее загрузки через сеть - ноль, и время активации до рабочего состояния тоже чаще всего ноль. А для того же питона - надо притащить 5-10 мб, а затем сколько то подождать компиляции и запуска. Без какого-то сохранения и переиспользования среды эта технология слабо применима для обычных сайтов.
очень высокие затраты на переупаковку данных. Вот был код JS с какой-то тормозной функцией, выносим функцию на производительный язык в webassembly и ... все также тормозит - потому что до 90% времени может съедать переупаковка структур данных между языками при маленьких и частых вызовах.
Не думаю, что без их решения доля на рынке как-то кардинально изменится.
izogfif
25.01.2025 14:21Для JS она уже встроена в любой браузер и время ее загрузки через сеть - ноль
А для того же питона - надо притащить 5-10 мб
И для Python-приложения, и для "обычного" WASM-приложения нужно загрузить бинарники. Для JavaScript-"приложения" нужно загрузить бандлы с JavaScript-кодом. Размер всех этих ресурсов в байтах сильно зависит от функционала, который реализован. Сама среда "исполнения" WASM-приложения, написанного на чем-то, что компилируется прямо в WASM (C, C++, Rust) уже есть внутри всех браузеров несколько лет. Ничего дополнительного скачивать не нужно.
Так что сравнивать, не имея исходных данных, нельзя. Это как сказать "вот раньше лошадь вывел из стойла, сел и поехал, а автомобиль нужно из гаража вывезти, двигатель прогреть, на заправку заехать" и т.п. Есть WASM-приложения, весящие мегабайт-два и выполняющие за секунды вычисления, для которых раньше требовались десятки мегабайт JavaScript-кода, выполнявшего те же самые вычисления минуты или часы.
mixsture
25.01.2025 14:21И для Python-приложения, и для "обычного" WASM-приложения нужно загрузить бинарники
несомненно. Но под существенным расширением доли рынка я понимаю возможность потеснить JS, поэтому мы приходим к сравнению JS vs (Wasm+нечто внутри). Если пытаться туда вставить некомпилируемые языки, то придется добавить к бандлу еще и среду исполнения. Вот для пайтона - это лишние 5-10 мб. Поэтому в текущей архитектуре мы сразу проигрываем по объему.
jooher
25.01.2025 14:21Интересная позиция. Вместо того, чтобы думать, как эффективно использовать то, что есть - придумывать сценарии, как это можно изговнякать тем, чего ещё нет.
JerryI
25.01.2025 14:21Можно в целом думать о WASM, как скажем native module в ноде, или binding к какой-то либе на С++ из питона и т.д.
Ratenti
25.01.2025 14:21Эм, лошадь тоже надо кормить
AlchemistDark
25.01.2025 14:21А ещё лошади болеют. Автомобиль проще во всех отношениях, он ведь тупо физически реализован проще.
Alexufo
25.01.2025 14:21Посмотрите как работает Yewstack - это почти реакт с настоящей типизацией.
Посмотрите как работают сайты на нкм. У вас отрисовка DOM заметно быстрее работает из-за того что весь сайт в wasm
slonopotamus
25.01.2025 14:21У вас отрисовка DOM заметно быстрее работает из-за того что весь сайт в wasm
Ммм... Что?
Alexufo
25.01.2025 14:21Ну не прям весь сайт, точнее компоненты и логика. Когда я щупал сайты на yew, по мне они работали довольно шустро. Из js там только прослойка малюсенькая.
konsoletyper
25.01.2025 14:21И для Python-приложения, и для "обычного" WASM-приложения нужно загрузить бинарники. Для JavaScript-"приложения" нужно загрузить бандлы с JavaScript-кодом
Проблема в том, что в JS есть "стандартная библиотека" - всякие
Array,Date,Math,Mapи т.д., и вся эта стандартная библиотека зашита прямо в браузер. Поэтому для JS надо грузить только сам код, реализующий логику. В случае c Python или Java - у них своя стандартная библиотека, реализация которой (даже в каком-то очень усечённом варианте) может весить несколько мегабайт, даже десятки мегабайт, и которую надо грузить по сети, помимо кода собственно приложения. Сам по себе Wasm не реализует ничего, похожего, например, наjava.util.ArrayList.izogfif
25.01.2025 14:21А почему вы упоминаете Java или Python? В C++ и Rust есть свои
std::vectorиstd::Vec(и куча других шаблонов) которые компилируются в WASM.konsoletyper
25.01.2025 14:21Я упоминаю Python, потому что отвечаю на ответ в комментарию, где упоминался Python. А Java я упоминаю потому, что у меня в этой области есть огромная экспертиза. А то, что и для C++ надо так же грузить стандартную библиотеку вместо использования готовой ещё больше подтверждает тезис автора изначального комментария, который я тут пытаюсь защитить, а именно:
тяжелая среда исполнения. Для JS она уже встроена в любой браузер и время ее загрузки через сеть - ноль, и время активации до рабочего состояния тоже чаще всего ноль. А для того же питона - надо притащить 5-10 мб, а затем сколько то подождать компиляции и запуска
JerryI
25.01.2025 14:21Зависит от того, как спроектировали. Если TypedArray, то передается ссылка, без переупаковки и всяких memcpy. А если надо работать с большими разношорстными объектами, то тут напрямую выгода от wasm может и не быть большой. Зачастую ускорять надо как-раз что-то однотипное.
RH215
25.01.2025 14:21Здесь похоже нужны языки или хотя бы компиляторы, которые изначально рассчитаны на исполнение в WebAsm.
aybel
25.01.2025 14:21Я так понимаю вы под "переупаковкой" данных говорите о сериализации и десериализации. В том же Blazor WASM есть два способа - это как раз та самая "переупаковка" с сериализацией/десериализией и, второй, маршаллинг. Маршаллинг работает очень быстро и позволяте "гонять" огромные массивы данных между средами webassembly и js. На самом деле проблема сериализации/десериализации - это проблема не только веба (но и взаимодействия наример с БД) и часто явялется узким местом производтельности. Это вопрос архитектуры и решаться он должен на этапе проектирования, причем решаться (рассматриваться, проектироваться) должен сквозь всё решение: от БД до DOM браузера.
konsoletyper
25.01.2025 14:21Это не сериализация/десериализация. Это просто банальная передача параметров между Wasm-модулем и JS API. Иногда эту передачу можно сделать почти бесшовной, иногда подходы к организации данных в JS, Wasm и гостевом языке настолько принципиально отличаются, что приходится либо что-то "переупаковывать" с соответствующими накладными расходами, либо прямо в гостевом языке городить какой-то страшнейший огород, сводящий на нет все преимущества от возможности писать на этом самом гостевом языке. Например, во всяких C++ библиотеках часто строки идут в памяти либо в виде
wchar_t*,либо дажеchar*в UTF-8. В JS строка хранится не в хипе, а в виде специального встроенного объекта, хранящего строку в UTF-16. Чтобы, например, нарисовать текст в canvas, приходится делать копирование (возможно даже с преобрвазованием UTF-8->UTF-16) там, где в случае чистого JS его можно было бы избежать. Другой пример - это передача JS-объектов между JS и Wasm-модулем - там надо организовывать некие таблицы соответствия, отображающие JS-объекты на хип Wasm.aybel
25.01.2025 14:21Понятно. Что касается передачи объектов (могу говорить за .net) - так и есть, приходится свойства раскладывать и сопоставлять между средами и подбирать наиболее оптимальную (для обоих сред и логики) структуру объекта. В тоже время такая рутина может оправдываться переносом в WASM ресурсоемких задач (я сталкивался с математическими вычислениями), кторые существенно разгрузят сервер за счёт использования ресурсов клиента.
ExTalosDx
25.01.2025 14:21а ещё переход на wasm создаст трудности с блокировкой рекламы. Которые всё равно можно обойти с помощью dns фильтра
Sabbone
25.01.2025 14:21В статье много раз повторяются одни и те-же утверждения. Используемые выражения и стиль статьи с высокой вероятностью указывает что она была написана нейросетью
SantaCluster
25.01.2025 14:21то, что написано нейросетью, будет прочитано нейросетью... :)
скоро научатся так генерировать, что и не отличишь. потом будем кряхтеть на завалинке "золотое было время - мы могли отличить то, что было сгенерировано нейросетью, не то, что нонча..." :)
Yak52
25.01.2025 14:21На самом деле, вместо статьи сгенерированной нейросетью, лучше публиковать промпт. Кому надо, те сами сгенерировали бы текст статьи.
george3
25.01.2025 14:21В браузере Firefox WebAssembly выполняется в 2,4 раза быстрее, чем в Chrome, и в 8,7 раз быстрее, чем в Edge по сравнению с JavaScript в аналогичных условиях.
Учитывая что Edge это Chromium звучит неправдоподобно. +почему сравнение Firefox Webassemply c Chome JS а не Firefox WS c Chome WS? кто так сравнивает и кто за этим стоит?
gmtd
25.01.2025 14:21Разве для 99.9% сайтов нужен где-то перформанс wasm-a?
techno_mot Автор
25.01.2025 14:21Справедливый вопрос. Для большинства сайтов WebAssembly действительно может показаться избыточеным и HTML, CSS и JS вполне справляются. Но если речь про что-то тяжёлое, например, сложные графические редакторы, игры или видеообр. прямо в браузере, тут без Wasm уже не обойтись. Всё зависит от задач, а не от процента :)
Avangardio
25.01.2025 14:21So-so насчет васма, циферки - буковки передавать легко, а вот объекты и что-то из реальных даных - начинается цирк с конями и обертками оберток и так далее… Ну и жс, разогнанный житом уменьшит разницу до реальных 20-30 процентов в сторону языка из васма, как ребята с Яндекс карт и получили, была статья здесь.
techno_mot Автор
25.01.2025 14:21Да, с передачей данных там весело, согласен. Но главное не только в скорости Васм дает возможность подключить серьёзные инструменты, которые JS просто не вытянет, типо, библиотек для работы с графикой или сложных алгоритмов. Так что, это больше про универсальность, чем про чистую производительность..
ByteByByte
25.01.2025 14:21Неплохая статья, все по делу. WebA реально интересен своими возможностями, где нужна высокая производительность. Круто, что упомянули про компиляцию в бинарный формат, это бустит возможности для веб-аппов.
Интересно, а как обстоят дела с его ограничениями, например, при работе с DOM? Реально ли совмещать его с JavaScript на практике, и есть ли примеры, где это эффективно работает?
techno_mot Автор
25.01.2025 14:21Пока что Васм с DOM напрямую работать не умеет, тут всё ещё рулит JS. Обычно его юзают для тяжёлых задач, где важна производительность, а весь интерфейс остаётся на JS. Например, в той же Figma Wasm обрабатывает графику, а всё остальное на JS. Но есть подвижки, WebAssembly Component Model обещает упростить эту интеграцию. Если интересно, вот ссылка, можно глянуть.
JBFW
Ключевая проблема здесь - разработчики ничего не знают о компьютерах пользователей, и будут ориентироваться на свои собственные компьютеры.
Ну там, скажем, простенькие, начального уровня - 16 гигабайт памяти, видеокарта предпоследнего поколения, канал по оптоволокну, безлимитный...
GiveMeFreeNickName
Эта проблема касается и других языков/технологий и причиной ее является не технология, а разработчик
techno_mot Автор
Да, проблема реальная не у всех есть “простенькие” 16 ГБ оперативки и оптоволокно. WASM конечно, помогает выжать максимум даже на слабых машинах, но, честно говоря, иногда кажется, что разработчики тестируют свои приложения исключительно на космических станциях.