Здравствуйте, vdimas, Вы писали:

_>>Ну так ты же сам пишешь, что в принципе JS с WebGL уже сам может почти всё.
V>WebGL не может ничего.
V>Это как голый AutoCAD без плагинов, где можно рисовать только плоскости, базовые фигуры и т.д.
V>Далеко ты таким макаром не уедешь, ес-но.
V>Это не то же самое, что работать с полным набором плагинов для архитектурного проектирования, к примеру.
V>Т.е. нужно будет портировать кучу либ на wasm.
V>А потом как-то разбираться с их версионированием и кешированием.
V>Потому что размер таких полноценных либ сегодня — десятки метров.

В принципе если библиотека использует только стандартную библиотеку C++ в сочетание с какой-то разновидностью OpenGL/OpenAL, то всё "портирование" сведётся к просто перекомпиляции под emscripten. Т.е. очень многие движки заведутся "с ходу". )

Скажем для портирования SDL (которая теперь кстати входит в стандартное API emscripten https://github.com/kripken/emscripten/tree/master/system/include) им наверное (я сам не смотрел детали) пришлось добавить на уровне js-кода только простейшие вещи (поддержку получения событий от мышки с клавой и всякие мелочи типа установки заголовка окна, перехода в полноэкранный режим и т.п.). А теперь любое приложение, работающее на базе SDL (а таких не мало) будет собираться под браузер простой перекомпиляцией. Причём это всё было ещё до wasm, просто под js. А wasm всего лишь добавит к этой уже существующей инфраструктуре быстродействие близкое к нативному.

_>>Единственно, что ему может не хватать, это производительности в некоторых случаях (например если мы хотим написать свой плеер видео, которому соответственно придётся декодировать h.264/h.265) и доступа к функциям ОС (например для общения со всякими железками).
V>Чего в JS не хватает — это нормального языка программирования и хорошо структурированных библиотек к нему. ))
V>Код клиентских приложений может быть (и должен быть) довольно-таки сложен.
V>Я пару раз пытался читать обзоры того, что сейчас пользуют из либ для JS — голова идёт кругом.
V>Там происходит идеальнейший в природе Хаос.

Ну так сейчас вот уже C/C++ добавились. Обещается в ближайшее время Rust. Может потом и всякие Java/C# подтянутся (хотя не очень понятно зачем они нужны для wasm, т.к. их код обычно не намного более быстродействующий, чем JS)...

V>Т.е., если в середине 90-х "из ничего" за 2-3 года появилось "всё", то сейчас всё изменилось, инерционность веба дикая.
V>Как и прежде, я вангую еще лет 5 минимум на "созревание" этой технологии.
V>При том, что ей уже пошёл 6-й год от первой демонстрации "вживую"...

Нуу использовать то на практике думаю можно будет уже прямо в этом году. А вот повсеместное распространение она не факт что и через 5 лет получит, просто потому что она реально не везде нужна. )))

_>>Первую проблему очевидно решает как раз wasm. А вторую в какой-то степени решает Native messaging API, позволяющий данному JS скрипту общаться с внешним нативным приложением, естественно имеющим доступ ко всему OS API (однако установить это приложение как плагин браузера не выйдет — нужная нормальная инсталляция).
V>И обратиться из кода страницы к такому приложению выйдет только в том случае, если оно получено из надёжного источника. Например, в WIN 8 и выше можно запустить по специальной браузерной ссылке установленное приложение. Это ссылка на страничку этого приложения в Магазине. Если приложение уже стоит — оно запустится. Если еще не стоит — откроется Магазин и предложит установить.
V>Осталось придумать, как ровно таким же образом из надёжных источников получать библиотеки для wasm.
V>Потом предкомпиллять их (АОТ) при инсталляции.
V>А потом посмотреть на всё это с высоты птичьего полёта и сделать вот так ...
V>Будет та же плагинная система, вид сбоку. ))

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