Comments 45
Насколько код скомпилированный и запущенный в wasm быстрее кода на JavaScript? Есть ли смысл писать вебигру под wasm?
Вот это правильный вопрос. Я всегда начинаю с примеров. Просто смотрите примеры и делайте выводы. Вот «Hello, World!» на WebAssembly: example.qt.io/qt-webassembly/opengl/hellowindow/hellowindow.html
Пока в Chrome приходится ждать, пока оно стартанет. Может пример кривой и где-то есть лучше?
Пока в Chrome приходится ждать, пока оно стартанет. Может пример кривой и где-то есть лучше?
Дело не в том, что пример кривой, дело в том, что Qt это тяжеленный монстр. И кто то придумал, что WebAssembly существует для компиляции всего кода перед запуском модуля. Отсюда же нулевая оптимизация интеграции с JS. И всё ради того, чтобы JIT не лагал во время игры. Firefox быстро пошёл на уступки компилируя в первый раз без оптимизаций, но в тоже время отбросил основную идею. А Google забил и к тому же вырубил кеш компиляции. Вот не сильно тормозной пример github.com/timhutton/opengl-canvas-wasm
Нет пока смысла, так как wasm не имеет доступа к DOM напрямую, только через JS. Т.е. wasm годится для узкого круга задач — напр. майнить биткоины в браузере через js и wasm (шютка).
Прямое общение с DOM предполагается лишь в будущем, вот тикет, который блокирует это: github.com/WebAssembly/design/issues/1079. Кроме панипуляций DOM напрямую для полноценного приложения не хватает встраивания и модульности с прозрачной интеграцией с существующими es6 модулями.
Прямое общение с DOM предполагается лишь в будущем, вот тикет, который блокирует это: github.com/WebAssembly/design/issues/1079. Кроме панипуляций DOM напрямую для полноценного приложения не хватает встраивания и модульности с прозрачной интеграцией с существующими es6 модулями.
Ну вот неплохая серия статей (статья, ответ (перевод на хабре), ответ на ответ), отсюда можно сделать вывод, что по крайней мере в конкретном примере идиоматичный код скомпилированный в WASM в 7 раз быстрее, чем неидиоматичный оптимизированный JS.
Кроме игр, пользователи ненавидели Flashyoutube тоже ненавидели? Или там swfupload? Пользователи зачастую просто не знали, что оно flash.
Эти платформы не взаимодействовуют с остальной платформой в браузереExternalInterface, не?
Мне вот кажется, что пока нормально не будет поддерживать Java/C#, то особой популярности он не найдёт. Я не против установить виртуальную машину один раз и пользоваться на всю катушку, но вот в плане основной платформы для разработки увы Wasm в нынешнем виде не подходит. В итоге 99% энтерпрайза просто проходит мимо.
Клепать игры? Браузерные? Ну да, можно, но большого смысла нет, высокий порог вхождения (нынешних JS программеров переучивать?), сложность разработки и отладки может привести к нерентабельности.
Пока вижу из реальных вариантов использования: Видео- и аудио-связь, удалённое управление. Ну и та ниша, для чего использовались Java-апплеты.
Даже если добавят возможность манипуляции DOM, то ничего не это не даст. Пользовательский код манипуляции DOM никогда не был узким местом, использовать Wasm для оптимизации смысла нет вообще. Единственный вариант — компиляция JS в Wasm, ради экономии трафика (спорно) и некоторой защиты от дурака.
Клепать игры? Браузерные? Ну да, можно, но большого смысла нет, высокий порог вхождения (нынешних JS программеров переучивать?), сложность разработки и отладки может привести к нерентабельности.
Пока вижу из реальных вариантов использования: Видео- и аудио-связь, удалённое управление. Ну и та ниша, для чего использовались Java-апплеты.
Даже если добавят возможность манипуляции DOM, то ничего не это не даст. Пользовательский код манипуляции DOM никогда не был узким местом, использовать Wasm для оптимизации смысла нет вообще. Единственный вариант — компиляция JS в Wasm, ради экономии трафика (спорно) и некоторой защиты от дурака.
Про PHP забыли :) С поддержкой PHP для клиентского кода может взлететь и без Java/C#.
Пользовательский код манипуляции DOM никогда не был узким местом
Берём любой редактор текста на реакте, загружаем в него документ на сотню килобайт и любуемся на тормоза при вводе каждой буквы. Чтобы изменить один небольшой текстовый узел идёт пара секунд вычислений. Современный JS — очень даже узкое место.
Минимально разумный пользователь не станет разрешать дырявоиу браузеру запускать на своей машине неизвестные блобы из Интернета.
Принципиальная читаемость JS кода — его важный плюс против джавы, флэша и прочего трэша.
Имхо, вместо использования браузера в качестве контейнера следует двигаться к контейниризации самого браузера.
Принципиальная читаемость JS кода — его важный плюс против джавы, флэша и прочего трэша.
Читаемость JS, пропущенного через какой-нибудь минификатор, будет вот разве что «принципиальной». А блобы WA, полагаю, принципиально должно быть возможно декомпилировать и почитать.
Даже декомпилировать не надо. Браузеры отображают его в текстовом формате.
Текстовая природа JS позволяет существовать и такому понятию, как XSS.
Обоюдоострый стул.
Обоюдоострый стул.
Минимально разумный пользователь не станет разрешать дырявоиу браузеру запускать на своей машине неизвестные блобы из Интернета.
Типа вы весь js на каждой странице читаете перед запуском?
А вот нафига, в самом деле, какому-либо приложению на веб-странице доступ к остальному DOM? Даже на чтение. Поэтому лично я люблю флэш — без спроса наружу не лезет, а для того, чтобы вылезать наружу, спрашивает ExternalInterface, а можно мне вон туда или нет (дыры в Flash — отдельная тема). С джавой, кстати, ещё веселее в этом плане, но она очень тяжелая в плане ВМ, она вообще вне браузера (что, впрочем, логичнее с точки зрения безопасности). А wasm выглядит так, что на нем будут эксплуатировать XSS, воровать сохраненные пароли или куки и потом деньги, причем быстрее, чем вы сможете сказать «Microsoft Firewall» :D
В теории не получится с помощью wasm своровать больше чем с помощью js. Сейчас песочница у wasm — подмножество песочницы js, планируется лишь расширить её до границ js.
А вот нафига, в самом деле, какому-либо приложению на веб-странице доступ к остальному DOM?
Для единообразия. Если я пишу ПО на языке X#, чтобы оно работало в браузере, то мне намного удобнее всё делать на X#, не перемешивая его с JavaScript.
> Кроме игр, пользователи ненавидели Flash, а Java-апплеты были тяжёлыми и медленными.
Флэш ненавидили сеошники, а не простые пользователи. Java-апплеты были тяжёлыми и медленными когда компьютеры были медленными, а в интернет выходили по диалапу. Сейчас это не так.
Флэш ненавидили сеошники, а не простые пользователи. Java-апплеты были тяжёлыми и медленными когда компьютеры были медленными, а в интернет выходили по диалапу. Сейчас это не так.
Пока в wasm есть один главный момент: он почти никак не подходит для запуска языков с GC, в результате по факту только на C++ да Rust под него сейчас и возможно писать.
Вот интересно стало, а какие ниши может занять wasm? Flash в свое время дал возможности, которые нельзя было реализовать без него и которые при этом были широко востребованы, потому так сильно распространился. Затем по мере расширения возможностей «нативных» средств, флеш начал терять ниши. Что может дать wasm, невозможного без него и при этом широко востребованного, чтобы закрепиться в индустрии?
На ум приходит какой-нить суровый софт под Chrome OS, но это не похоже на большую нишу.
На ум приходит какой-нить суровый софт под Chrome OS, но это не похоже на большую нишу.
Web( и JS ) как таковой, уже достиг пределов своего развития( в плане количества задействованных разработчиков. Число, конечно, будет постепенно расти, но не так быстро, как некоторым хотелось бы ).
Чтобы активно развиваться дальше, нужно поглощать других: как разрабов с других языков, так и наработанные за многие годы кодовые базы.
Вот, посредством WebAssembly, это и реализуется: web в общем и js в частности, постепенно начинают «поглощать» остальных, делая js и его подобие, по сути, универсальным языком.
Почему именно WebAssembly, а не просто преобразование в обычный js?
Потому, что, если в языках используется-таки статическая типизация, грех не получить с этого профит.
Чтобы активно развиваться дальше, нужно поглощать других: как разрабов с других языков, так и наработанные за многие годы кодовые базы.
Вот, посредством WebAssembly, это и реализуется: web в общем и js в частности, постепенно начинают «поглощать» остальных, делая js и его подобие, по сути, универсальным языком.
Почему именно WebAssembly, а не просто преобразование в обычный js?
Потому, что, если в языках используется-таки статическая типизация, грех не получить с этого профит.
Вот интересно стало, а какие ниши может занять wasm?
Ну представь себе облачный кроссплатформенный фотошоп.
Это да, но есть ли широкий спрос на такие продукты? Особенно при условии, что частично это можно сделать и без webasm, закрыв любительскую аудиторию. Тот же pixlr — отличный фотошоп для любителей, соотв переходить на полноценный аналог на webasm-е им будет незачем.
Спрос есть. Иначе бы не было Asm.js, а Google бы не делала NaCL.
Только вот wasm ужасающе убог в сравнении ними обоими. Нет исключений, динамической линковки, кодогенерации; NaCL ещё и имеет бинарный API и не имеет необходимости в компиляции в браузере. Что есть в wasm? Есть только обещание, что всё это будет исправлено в будущем. Но судя по тому, как быстро принимаются спецификации HTML и JS и как медленно wasm, последний вероятно будет так же распространён как язык D.
Какой кодогенерации не хватает? Динамическая линковка, а она есть при компиляции C/C++ в asm.js?
последний вероятно будет так же распространён как язык D.
Компиляция C/C++ в Asm.js получила распространненость, почему wasm не должен?
Какой кодогенерации не хватает?Невозможно в процессе работы создать новый wasm-код и тут же его использовать.
Динамическая линковка, а она есть при компиляции C/C++ в asm.js?Технически это возможно и в emscripten уже есть экспериментальная поддержка. Но они почему то считают, что если слить всё в один гигантский файл, то производительность будет лучше.
Компиляция C/C++ в Asm.js получила распространненость, почему wasm не должен?Потому, что медленнее вызывает импортируемые функции чем Asm.js. Или потому, что обратную совместимость с Asm.js всё равно придётся делать. Или потому, что вынужден таскать дополнительный JS-файл с бесчисленными обертками. Или потому, что простейшее Qt-OpenGL приложение в Chrome компилируется секунд 30, при каждом запуске…
Невозможно в процессе работы создать новый wasm-код и тут же его использовать.
А на C/C++ что-нибудь такое можно? А в чем достоинства динамической линковки? Для работы все равно нужно это загрузить и скомпилировать.
Потому, что медленнее вызывает импортируемые функции чем Asm.js.
Где бенчмарки на реальных проектах?
Или потому, что обратную совместимость с Asm.js всё равно придётся делать.
Её так и так нужно делать, т.к. не все пользователи обновили свои браузеры. Для emscripten это всего один флаг линковки.
Или потому, что простейшее Qt-OpenGL приложение в Chrome компилируется секунд 30, при каждом запуске…
Не используйте Qt, мы не использует Qt и 20Mb wasm кода компилируется на десткопах незаметно. В случае asm.js вы будете так же тратить время на компиляцию, но уже на JIT компиляцию. Это приводит к тому, что на iOS приложение может длительно тормозить, пока JIT все не откомпилирует.
1) ресурсоемкие, правда тут ему на пяты наступает JIT в JS.
2) перенос части кодовой базы с сервера на клиент
2) перенос части кодовой базы с сервера на клиент
Sign up to leave a comment.
WebAssembly — это возвращение апплетов Java и Flash?