Comments 45
Насколько код скомпилированный и запущенный в wasm быстрее кода на JavaScript? Есть ли смысл писать вебигру под wasm?
Пока в Chrome приходится ждать, пока оно стартанет. Может пример кривой и где-то есть лучше?
Прямое общение с DOM предполагается лишь в будущем, вот тикет, который блокирует это: github.com/WebAssembly/design/issues/1079. Кроме панипуляций DOM напрямую для полноценного приложения не хватает встраивания и модульности с прозрачной интеграцией с существующими es6 модулями.
Кроме игр, пользователи ненавидели Flashyoutube тоже ненавидели? Или там swfupload? Пользователи зачастую просто не знали, что оно flash.
Эти платформы не взаимодействовуют с остальной платформой в браузереExternalInterface, не?
Клепать игры? Браузерные? Ну да, можно, но большого смысла нет, высокий порог вхождения (нынешних JS программеров переучивать?), сложность разработки и отладки может привести к нерентабельности.
Пока вижу из реальных вариантов использования: Видео- и аудио-связь, удалённое управление. Ну и та ниша, для чего использовались Java-апплеты.
Даже если добавят возможность манипуляции DOM, то ничего не это не даст. Пользовательский код манипуляции DOM никогда не был узким местом, использовать Wasm для оптимизации смысла нет вообще. Единственный вариант — компиляция JS в Wasm, ради экономии трафика (спорно) и некоторой защиты от дурака.
Пользовательский код манипуляции DOM никогда не был узким местом
Берём любой редактор текста на реакте, загружаем в него документ на сотню килобайт и любуемся на тормоза при вводе каждой буквы. Чтобы изменить один небольшой текстовый узел идёт пара секунд вычислений. Современный JS — очень даже узкое место.
Минимально разумный пользователь не станет разрешать дырявоиу браузеру запускать на своей машине неизвестные блобы из Интернета.
Принципиальная читаемость JS кода — его важный плюс против джавы, флэша и прочего трэша.
Имхо, вместо использования браузера в качестве контейнера следует двигаться к контейниризации самого браузера.
Принципиальная читаемость JS кода — его важный плюс против джавы, флэша и прочего трэша.
Читаемость JS, пропущенного через какой-нибудь минификатор, будет вот разве что «принципиальной». А блобы WA, полагаю, принципиально должно быть возможно декомпилировать и почитать.
Обоюдоострый стул.
Минимально разумный пользователь не станет разрешать дырявоиу браузеру запускать на своей машине неизвестные блобы из Интернета.
Типа вы весь js на каждой странице читаете перед запуском?
А вот нафига, в самом деле, какому-либо приложению на веб-странице доступ к остальному DOM?
Для единообразия. Если я пишу ПО на языке X#, чтобы оно работало в браузере, то мне намного удобнее всё делать на X#, не перемешивая его с JavaScript.
Флэш ненавидили сеошники, а не простые пользователи. Java-апплеты были тяжёлыми и медленными когда компьютеры были медленными, а в интернет выходили по диалапу. Сейчас это не так.
Пока в wasm есть один главный момент: он почти никак не подходит для запуска языков с GC, в результате по факту только на C++ да Rust под него сейчас и возможно писать.
На ум приходит какой-нить суровый софт под Chrome OS, но это не похоже на большую нишу.
Чтобы активно развиваться дальше, нужно поглощать других: как разрабов с других языков, так и наработанные за многие годы кодовые базы.
Вот, посредством WebAssembly, это и реализуется: web в общем и js в частности, постепенно начинают «поглощать» остальных, делая js и его подобие, по сути, универсальным языком.
Почему именно WebAssembly, а не просто преобразование в обычный js?
Потому, что, если в языках используется-таки статическая типизация, грех не получить с этого профит.
Вот интересно стало, а какие ниши может занять wasm?
Ну представь себе облачный кроссплатформенный фотошоп.
Спрос есть. Иначе бы не было Asm.js, а Google бы не делала NaCL.
Какой кодогенерации не хватает? Динамическая линковка, а она есть при компиляции 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 все не откомпилирует.
2) перенос части кодовой базы с сервера на клиент
WebAssembly — это возвращение апплетов Java и Flash?