Почему WebAssembly всё ещё не переплюнул JS и TS

Узнали у мидл и сеньор-разработчиков, почему WebAssembly, который считается "ускоренным JS", так и не стал популярнее классического JS, TypeScript или CoffeeScript за почти десятилетие.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Сергей Спицын

Эксперт разработки ГК Юзтех 

Если мы обратимся к сайту, то сможем увидеть те цели, с которым создавался WebAssembly. Это быстрота/эффективность, безопасность, простая отладка и возможность переноса нативных приложений в веб. Если со скоростью, отладкой и безопасностью более-менее понятно из названия, то на счёт желания проникнуть в веб с первого взгляда — не очень. Но оно обусловлено несколькими факторами. Один из них — простота доставки изменений. Как мы помним, из взаимодействия с нативными программами, нам нужен либо какой-то пакетный менеджер, либо магазин, который будет доставлять обновления нашим клиентам. В случае с вебом, нам достаточно обновить код на наших серверах и наши клиенты при следующем открытии нашего сайта/приложения получат все наши изменения. Ещё одним фактором проникновения в веб является задача кроссплатформенности. У нас есть прекрасные утилиты и приложения, которые можно было бы без переписывания или с минимальными изменениями сделать доступными в наших веб приложениях.

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

Если речь идёт о сравнении производительности JavaScript и WebAssembly, то в общих случаях она будет сопоставимой, а в частных — действительно можно достичь определенного прироста. Но всё это при условии что не будет использоваться браузерный API, ибо если мы начнём манипулировать DOM деревом, то очень скоро упрёмся в производительность перерисовки DOM элементов.

Помню тот период, когда WebAssembly находился на стадии разработки и почти каждый разработчик, который не имел опыта написания веб приложений говорил “вот появится поддержка моего языка в WebAssembly, и я буду писать интерфейсы, и наконец-то исчезнет этот ваш JavaScript”. На данный момент в продуктивной среде можно использовать C/C++/Rust/Golang и ещё множество языков с разной степенью готовности. Пример. 

Как мы видим, языки, готовые для продуктива, имеют высокий порог входа и не могут конкурировать с JavaScript в плане легкости освоения. При этом разработчики C/C++/etc не спешат переходить в frontend разработчики. Энтузиасты ведущие разработку на других языках и ранее (до появления WebAssembly) имели возможность писать код на своём любимом языке вместо JavaScript, взгляните на https://brython.info/. Даже мне удалось повстречать самобытный генератор JavaScript кода из Python кода. Но таких энтузиастов единицы: они не закрывают потребность рынка, а надёжность таких решений вызывает сомнения. Часть этих ребят могла бы перейти на WebAssembly и развивать компилятор под свой язык, но это не составляет конкуренции JavaScript.

 Думаю, никому из вас не хотелось бы попасть на проект, на котором используется вот такое непопулярное решение, пусть и на любимом языке программирования. Хотя…

На сегодняшний день, вокруг JavaScript выросла большая экосистема. У нас есть всё что нужно для разработки: пакетные менеджеры, фреймворки, библиотеки компонентов, различные инструменты. В троицу frontend фреймворков по сей день не может попасть ни один другой фреймворк. Да, инструменты для WebAssembly тоже развивались, появились фреймворки работающие с DOM, но вы, как и я, наверняка о них ничего не слышали. Мы смеёмся над frontend фреймворками и библиотеками, которые десятками появляются каждый день, и тут же умирают. Пока писал этот текст и искал фреймворки для написания веб приложений с компиляцией в WebAssembly повстречал немало ссылок, которые ведут на нерабочие сайты. В целом, всё это не выглядит живым и перспективным, посмотрите пример кода этого фреймворка.

С браузером и frontend разработкой всё стало немного понятнее, но у нас же есть ещё серверная среда исполнения — Node.js. Но и там возможность писать кастомные модули, расширяя возможности самой Node.js, или переносить сложные вычисления в реализацию на языке более низкого уровня, была давно, и многие использовали в случае необходимости. 

             WebAssembly используется в Node.js точечно, когда в этом возникает необходимость. Писать полную реализацию в WebAssembly просто нет необходимости, проще тогда использовать микросервисный подход и писать реализацию целиком на том языке, на котором нравится.

На мой взгляд, самым лучшим назначением для WebAssembly является возможность кросплатформенного переноса. Хорошим примером будет Figma. AutoCAD презентовал, что они смогли перенести 30-летнюю кодовую базу в веб благодаря WebAssembly.

Исходя из всего вышеизложенного, достаточно просто ответить на вопрос “Почему WebAssembly не заменил JavaScript или не стал популярнее? ”. Потому что WebAssembly это инструмент для решения узкого круга специализированных задач.

Алексей Лукинов

Sr разработчик ITQuick

Начнем с того, что WebAssembly, несомненно, имеет своё коммьюнити. Однако мир JavaScript развивался около 30 лет и за это время “оброс”, такими мощными и функциональными фреймворками как, например: Angular, Vue и React. Также JavaScript используется в клиентском коде для приложений на языке PHP – всё это делает JavaScript самым популярным языком программирования в мире.

Сравнивать с ним малое подмножество малой выборки - довольно странно. Капля не сможет вытеснить море, тем более, что в клиентских приложениях, использующих WebAssembly, зачастую, также используется и JavaScript или TypeScript.

WebAssembly начал свой “путь к успеху” только в июне 2019 года, когда был выпущен Chrome 75 с включенными по умолчанию потоками WebAssembly. Но началом попыток серьёзного использования WebAssembly в мире .NET можно считать 2020-й год, благодаря выходу Blazor WebAssembly 3.2.0, и с тех пор комьюнити, использующее WebAssembly, постоянно растёт.

Так как WebAssembly  построены на стековой виртуальной машине, исполняющей инструкции бинарного формата, они позволяет выполнять клиентский код на традиционно “серверных” языках программирования, таких как C, C++, C#, Rust, Go, что позволяет использовать на стороне клиента, в браузере, всю вычислительную и алгоритмическую мощь этих языков.

Это даёт ощутимые преимущества в быстродействии и функциональности клиентских приложений, по сравнению с JavaScript, TypeScript и CoffeeScript. Но так же требует других знаний и умений от прикладного разработчика клиентской части приложения. Именно это, на мой взгляд, тормозит расширение комьюнити WebAssembly, так как требует для написания клиентского кода более дорогих “серверных” программистов, коих и так постоянно не хватает.

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

Ну и какой-нибудь вывод, если он нужен:

Так что вернуться к данному сравнению имеет смысл ещё через пару-тройку лет, за которые, WebAssembly, конечно, не догонит JavaScript, тем более, что чаще всего они используются совместно, но можно будет оценить скорость распространения популярности WASM и сделать уже более обоснованные выводы по поводу данной технологии.

Алексей Каньков

Senior Backend Developer в компании Revizto

Есть ряд причин, по которым WebAssembly не набрал популярности в веб-разработке.

1. JavaScript существует уже почти 30 лет и за это время сформировалась огромная экосистема библиотек, инструментов и сообщество разработчиков. WebAssembly, анонсированный в 215 году и выпушенный в свет 2017, все еще играет роль "догоняющего".
2. JavaScript является языком, доступным для изучения и использования широкому кругу веб-разработчиков. WebAssembly требует навыков низкоуровневого программирования на языках C/C++/Rust/Kotlin, что сужает круг потенциальных разработчиков.
   
3. WebAssembly был задуман в первую очередь для обеспечения высокой производительности для ресурсоемких задач (игры, компьютерное зрение, криптография и т.д.). Для большинства веб-приложений JavaScript/TypeScript вполне достаточны.
   
4. Согласно опросам StackOverflow за 2019 год, JavaScript используется 67.8% разработчиков, TypeScript - 21.2%, в то время как WebAssembly - всего 1.2%. К 2023 году JavaScript опустился до 63.6%, TypeScript вырос в популярности до 38.9%, а WebAssembly совсем пропал из списка популярных технологий.
   

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

1. Игры и мультимедиа.
2. Научные вычисления, машинное обучение (TensorFlow.js, Lingon.js).
   
3. Криптография (Bitcoin, Ethereum).
   
4. Компьютерная графика, CAD, 3D-моделирование.
   

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

Андрей Макаров

Lead developer Islamic Coin

Основная причина, на мой взгляд почему webassembly не особо сильно распространен - необходимость изучать дополнительные языки программирования + связывание данных (из js в webassembly и наоборот) происходят не настолько удобно как этого хотелось бы рядовому разработчику, особенно это касается C++.

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

В проде моего кода с webassembly нет, но для себя пробовал делать с c++ и rust (последний на мой взгляд гораздо более удобный).

Юлия Румянцева

Руководитель отдела Web-разработки ГК Альфа-Лизинг

У команды в ГК Альфа-Лизинг есть небольшой опыт использования WASM, недавно протестировали пару внутренних утилит на Blazor (WASM от Microsoft), чтобы ознакомиться с технологией и оценить ее перспективы и применимость для задач. Этим занимались backend-разработчики, которые отметили ряд преимуществ: разработка на привычном C#, небольшой объем кода, эффективный отлов ошибок на этапе компиляции.

Однако выявились и некоторые минусы. Во-первых, достаточно сырая библиотека Blazor, непонятны перспективы ее поддержки и развития как со стороны Microsoft (Silverlight когда-то тоже выглядел перспективным), так и со стороны разработчиков браузеров.

Во-вторых, объем сборки WASM в несколько раз превышает размер JS-бандла. 0.8 мегабайт на Angular vs 4 мегабайта на Blazor. При этом убедительных аргументов в пользу webassembly с точки зрения бизнеса не найдено. JS уже привычен, понятен и удовлетворяет всем нашим требованиям. Как правило в b2b frontend не на сколько ресурсоемкий, чтобы раскрыть возможные преимущества WebAssembly в производительности.

Лично у меня есть еще одно опасение. Эволюция процесса разработки ПО привела к усилению специализации. Те, кому ближе интерфейсы переключились на разработку фронта, а те, кому ближе базы и API - ушли в бэкенд. WASM в этом смысле толкает нас назад.

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

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.