Комментарии 52
Ключевая проблема здесь - разработчики ничего не знают о компьютерах пользователей, и будут ориентироваться на свои собственные компьютеры.
Ну там, скажем, простенькие, начального уровня - 16 гигабайт памяти, видеокарта предпоследнего поколения, канал по оптоволокну, безлимитный...
Эта проблема касается и других языков/технологий и причиной ее является не технология, а разработчик
Да, проблема реальная не у всех есть “простенькие” 16 ГБ оперативки и оптоволокно. WASM конечно, помогает выжать максимум даже на слабых машинах, но, честно говоря, иногда кажется, что разработчики тестируют свои приложения исключительно на космических станциях.
А что если вместо браузера изобретут что-то, что позволит открывать прям бинарники например! Так если призадуматься браузер здесь, как костыль. Все равно взаимодействие с ним писать на JS. Но такую систему никто не придумал вместо браузеров. Так что эта технология будет там использоваться где она реально нужна… для дорогих расчетов! Хотя это не факт. Условная figma так написана, если я не путаю. И последнее время она тормозит, как любое веб приложение, и жрет памяти, как не в себя….
С учётом того, что Веб как таковой быстро теряет популярность, а весь контент уходит в мессенджеры, у WebAssembly на мой взгляд нет никакого будущего. Его как раз допилят к шапочному разбору, когда все будут сидеть по разного рода WeChat'ам с Discord'ами, через которые будет осуществляться всё - общение, просмотр контента, оплата сервисов...
Веб приложения, например фигму, вы в дискорде не запустите, с популярностью веба ничего не случится, вы кажется забыли что интернет это не только новости читать
Все эти фигмы и дискорды гораздо лучше было бы писать на C++ или другом нормальном языке и компилировать в нативное приложение для соответствующей операционной системы, а не пытаться запихнуть в браузер то, для чего он не предназначен.
Фигма как раз и написана на C++, который компилируется в WASM!
https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
С другой стороны фигма это почти по масштабам как ФШ, или иллюстратор. Они тоже кушают бывает много. Ну и команда их больше и времени у них на эволюцию было больше.
как раз такая же мысль вертится, насчёт бинарников, но браузер пока что хороший костыль, ибо связывает все четыре основные религии операционные системы, по сути превращаясь в виртуальную машину.
Да, было бы круто, изобрести какой-нибудь рантайм и портировать его на разные платформы, чтобы везде его ставили, а приложения распространять в виде предкомпилированного для этого рантайма кода. Тогда и браузер был бы не нужен. Но можно в браузере показывать апплеты, исполняемые этим рантаймом…
Никто, наверное, до такого не додумался пока.
Эм.... Flash, Java applets или Silverlight?
Я для себя отмечаю 2 огромных недостатка в этой технологии:
тяжелая среда исполнения. Для JS она уже встроена в любой браузер и время ее загрузки через сеть - ноль, и время активации до рабочего состояния тоже чаще всего ноль. А для того же питона - надо притащить 5-10 мб, а затем сколько то подождать компиляции и запуска. Без какого-то сохранения и переиспользования среды эта технология слабо применима для обычных сайтов.
очень высокие затраты на переупаковку данных. Вот был код JS с какой-то тормозной функцией, выносим функцию на производительный язык в webassembly и ... все также тормозит - потому что до 90% времени может съедать переупаковка структур данных между языками при маленьких и частых вызовах.
Не думаю, что без их решения доля на рынке как-то кардинально изменится.
Для JS она уже встроена в любой браузер и время ее загрузки через сеть - ноль
А для того же питона - надо притащить 5-10 мб
И для Python-приложения, и для "обычного" WASM-приложения нужно загрузить бинарники. Для JavaScript-"приложения" нужно загрузить бандлы с JavaScript-кодом. Размер всех этих ресурсов в байтах сильно зависит от функционала, который реализован. Сама среда "исполнения" WASM-приложения, написанного на чем-то, что компилируется прямо в WASM (C, C++, Rust) уже есть внутри всех браузеров несколько лет. Ничего дополнительного скачивать не нужно.
Так что сравнивать, не имея исходных данных, нельзя. Это как сказать "вот раньше лошадь вывел из стойла, сел и поехал, а автомобиль нужно из гаража вывезти, двигатель прогреть, на заправку заехать" и т.п. Есть WASM-приложения, весящие мегабайт-два и выполняющие за секунды вычисления, для которых раньше требовались десятки мегабайт JavaScript-кода, выполнявшего те же самые вычисления минуты или часы.
И для Python-приложения, и для "обычного" WASM-приложения нужно загрузить бинарники
несомненно. Но под существенным расширением доли рынка я понимаю возможность потеснить JS, поэтому мы приходим к сравнению JS vs (Wasm+нечто внутри). Если пытаться туда вставить некомпилируемые языки, то придется добавить к бандлу еще и среду исполнения. Вот для пайтона - это лишние 5-10 мб. Поэтому в текущей архитектуре мы сразу проигрываем по объему.
Можно в целом думать о WASM, как скажем native module в ноде, или binding к какой-то либе на С++ из питона и т.д.
Эм, лошадь тоже надо кормить
Посмотрите как работает Yewstack - это почти реакт с настоящей типизацией.
Посмотрите как работают сайты на нкм. У вас отрисовка DOM заметно быстрее работает из-за того что весь сайт в wasm
И для Python-приложения, и для "обычного" WASM-приложения нужно загрузить бинарники. Для JavaScript-"приложения" нужно загрузить бандлы с JavaScript-кодом
Проблема в том, что в JS есть "стандартная библиотека" - всякие Array, Date, Math, Map и т.д., и вся эта стандартная библиотека зашита прямо в браузер. Поэтому для JS надо грузить только сам код, реализующий логику. В случае c Python или Java - у них своя стандартная библиотека, реализация которой (даже в каком-то очень усечённом варианте) может весить несколько мегабайт, даже десятки мегабайт, и которую надо грузить по сети, помимо кода собственно приложения. Сам по себе Wasm не реализует ничего, похожего, например, на java.util.ArrayList.
А почему вы упоминаете Java или Python? В C++ и Rust есть свои std::vector и std::Vec (и куча других шаблонов) которые компилируются в WASM.
std::Vec тоже надо грузить.
Я упоминаю Python, потому что отвечаю на ответ в комментарию, где упоминался Python. А Java я упоминаю потому, что у меня в этой области есть огромная экспертиза. А то, что и для C++ надо так же грузить стандартную библиотеку вместо использования готовой ещё больше подтверждает тезис автора изначального комментария, который я тут пытаюсь защитить, а именно:
тяжелая среда исполнения. Для JS она уже встроена в любой браузер и время ее загрузки через сеть - ноль, и время активации до рабочего состояния тоже чаще всего ноль. А для того же питона - надо притащить 5-10 мб, а затем сколько то подождать компиляции и запуска
Стандартная библиотека для JS на самом деле скудная. Не случайно каждый раз тащили jquery, а сейчас все тащат lodash, axios, moment, uuid. Думаю отсюда и возник зоопарк фреймворков, ведь когда нет стандартной библиотеки каждый вертит как он хочет.
Зависит от того, как спроектировали. Если TypedArray, то передается ссылка, без переупаковки и всяких memcpy. А если надо работать с большими разношорстными объектами, то тут напрямую выгода от wasm может и не быть большой. Зачастую ускорять надо как-раз что-то однотипное.
Здесь похоже нужны языки или хотя бы компиляторы, которые изначально рассчитаны на исполнение в WebAsm.
Я так понимаю вы под "переупаковкой" данных говорите о сериализации и десериализации. В том же Blazor WASM есть два способа - это как раз та самая "переупаковка" с сериализацией/десериализией и, второй, маршаллинг. Маршаллинг работает очень быстро и позволяте "гонять" огромные массивы данных между средами webassembly и js. На самом деле проблема сериализации/десериализации - это проблема не только веба (но и взаимодействия наример с БД) и часто явялется узким местом производтельности. Это вопрос архитектуры и решаться он должен на этапе проектирования, причем решаться (рассматриваться, проектироваться) должен сквозь всё решение: от БД до DOM браузера.
Это не сериализация/десериализация. Это просто банальная передача параметров между 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.
Понятно. Что касается передачи объектов (могу говорить за .net) - так и есть, приходится свойства раскладывать и сопоставлять между средами и подбирать наиболее оптимальную (для обоих сред и логики) структуру объекта. В тоже время такая рутина может оправдываться переносом в WASM ресурсоемких задач (я сталкивался с математическими вычислениями), кторые существенно разгрузят сервер за счёт использования ресурсов клиента.
а ещё переход на wasm создаст трудности с блокировкой рекламы. Которые всё равно можно обойти с помощью dns фильтра
В статье много раз повторяются одни и те-же утверждения. Используемые выражения и стиль статьи с высокой вероятностью указывает что она была написана нейросетью
то, что написано нейросетью, будет прочитано нейросетью... :)
скоро научатся так генерировать, что и не отличишь. потом будем кряхтеть на завалинке "золотое было время - мы могли отличить то, что было сгенерировано нейросетью, не то, что нонча..." :)
На самом деле, вместо статьи сгенерированной нейросетью, лучше публиковать промпт. Кому надо, те сами сгенерировали бы текст статьи.
И ведь такие статью читают и даже лайкают. И никто с этим здесь ничего не делает.
В браузере Firefox WebAssembly выполняется в 2,4 раза быстрее, чем в Chrome, и в 8,7 раз быстрее, чем в Edge по сравнению с JavaScript в аналогичных условиях.
Учитывая что Edge это Chromium звучит неправдоподобно. +почему сравнение Firefox Webassemply c Chome JS а не Firefox WS c Chome WS? кто так сравнивает и кто за этим стоит?
Разве для 99.9% сайтов нужен где-то перформанс wasm-a?
Справедливый вопрос. Для большинства сайтов WebAssembly действительно может показаться избыточеным и HTML, CSS и JS вполне справляются. Но если речь про что-то тяжёлое, например, сложные графические редакторы, игры или видеообр. прямо в браузере, тут без Wasm уже не обойтись. Всё зависит от задач, а не от процента :)
So-so насчет васма, циферки - буковки передавать легко, а вот объекты и что-то из реальных даных - начинается цирк с конями и обертками оберток и так далее… Ну и жс, разогнанный житом уменьшит разницу до реальных 20-30 процентов в сторону языка из васма, как ребята с Яндекс карт и получили, была статья здесь.
Да, с передачей данных там весело, согласен. Но главное не только в скорости Васм дает возможность подключить серьёзные инструменты, которые JS просто не вытянет, типо, библиотек для работы с графикой или сложных алгоритмов. Так что, это больше про универсальность, чем про чистую производительность..
Неплохая статья, все по делу. WebA реально интересен своими возможностями, где нужна высокая производительность. Круто, что упомянули про компиляцию в бинарный формат, это бустит возможности для веб-аппов.
Интересно, а как обстоят дела с его ограничениями, например, при работе с DOM? Реально ли совмещать его с JavaScript на практике, и есть ли примеры, где это эффективно работает?
Пока что Васм с DOM напрямую работать не умеет, тут всё ещё рулит JS. Обычно его юзают для тяжёлых задач, где важна производительность, а весь интерфейс остаётся на JS. Например, в той же Figma Wasm обрабатывает графику, а всё остальное на JS. Но есть подвижки, WebAssembly Component Model обещает упростить эту интеграцию. Если интересно, вот ссылка, можно глянуть.
Если накосячить с сишными указателями, Wasm тоже падает с segfault?
А есть либы/фреймворки для языков типа С++/Rust, что то типа делфи, но что бы все окошки компилировались и работали в WASM?
Веб-приложения будущего: что нужно знать о WebAssembly