V8, WebKit, и др. используют Wasm только для вызовов и приёма ответов от процедур а байт код выполняется в отдельном модуле/потоке, или Wasm более тесно интегрирован с движками браузеров?
Зачем тогда mono принимает участие в его работе, если WebAssembly в вакууме не зависит от движка и сам может спарсить документ, то что там просится, mono для безопасности. Или mono тоже запускается как отдельный процесс на ноде. Где можно посмотреть простую схему какие там технологии под капотом, и что куда откуда передаётся?
Melonwatr1, сначала разберись что такое WebAssembly, что эта штука из себя представляет, какие там ограничения, где это применимо, много вопросов отпадет сразу. Мне лично лень это тут втирать, но от себя скажу, что в текущих реалиях веб разработки, применения это технологии не нашел.
Melonwatr1, Сейчас есть много хорошего кода на плюсах для десктопа, при помощи WASM и WASI(Это очень интерессно) можно будет много софта просто собрать под браузер немного переделав. А софт использующий STL вообще просто тупо собрать под браузер. То что ты сможешь любой язык компилить под браузер это конечно интерессно но много приемущества это тебе не даст. Индустрия десктопа никогда не переедет на Rust также и Индустрия фронтенда на F# или Python. Просто потому что найти Scala Front-end в команду скала фронтенд разработчиков будет не риально. Таких извращенцев будет максимум пару на весь мир.
можно будет много софта просто собрать под браузер немного переделав
Не немного, а весь рендер и всю работу с браузерным API. И вот то, что останется, а это какая-то обработка данных, вот это и будет в wasm. Все остальное надо будет писать на js.
Просто для примера, скомпилируй под браузер, "немного переделав", калькулятор майкрософта, исходники которого они уже зарелизили на гитхабе.
profesor08, Да. Но QT скорее всего оставят тотже интерфейс для web приложения и просто все будут рендерить в Canvas браузера. Я имеюю виду что идея WA такова. Но в реальности понятное дело все не так радужно. Вообще я думаю что для взаимодействия с интерфейсом будет только Assembly Script - диалект JS который компилиться под WA. Все остальное будет использоваться на бизнес уровне.
Вообще не пойму какой понт с Elixir, Java, Python или Go на фронте. Про C++ также можно сказать. Главная идея это возможность перенести готовый код коего много на плюсах - писанный годами. Вторая - браузерные игры, дать возможность создать безопасные(приложения которые работают в капсуле браузер и дальше нее просто никак не могут пойти) и в то же время производительные приложения. Unreal вроде бы уже что то придумали для сборки игры под браузер на основе WA
Pantene742, ну так весь рендер в canvas и есть 100% работа с браузерным api, через это api ты делаешь вызовы отрисовки, компилишь шейдеры и передаешь их на гпу. Если это будет доступно отдельно через wasm, то круто, но это отдельный поток со всеми вытекающими, и результат будет мееее... Пробовал перекидывать вычисления на другой поток с помощью сервис воркеров, и был разочарован.
profesor08, Я думаю должен быть результат отрисовки(как sharedMemory или просто переменная) что то типо как виртуал дома в реакте и он должен взаимодействовать с рельным Canvas когда потоки завершили свой цикл и пора показать кадр. Это уже разработка игрового движка. говорить об этом как о тривиальной задаче грех, так как это унижает разрабов движков и рендеров. Пока создатели WASI встретили много проблем и думаю видвинули требования для разработчиков Хромиума и Мозилы. Но когда WASI интерфейс сделают это будет круто, программу под интерфейс WASI можно будет запустить на мобиле, десктопе или браузере. WASI - Это стандарт типа POSIX только он включает в себя еще набор низкоуровневых системных вызовов и их реализацию на всех видах платформ в т.ч браузер.
Pantene742, WASI не предназначен для запуска в браузере, там он не будет НИКОГДА. Дело в том, что Mozilla очень против добавления в браузер дополнительных языков для создания приложений. Допустимы только библиотеки находящиеся в песочнице из JS кода. Цель существования WASI в создания изолированных микросервисов, чтобы приложения на Си могли запускать изолированный WASM код. Конечно такой WASM-код может быть запущен в браузере, если на JS реализовать стандартные WASI API.
none7, webassembly это впринципе часть JS, сдесь насколько я понимаю больше всего работали именно создатели компиляторов, которые смогли сделать back-end часть компилятора под данную платформу(LLVM to Webassembly). У меня только вопросс как обстоит дело с C# и Java и другие даже PHP. У этих нету ручной уборки мусора, им нужен интерпритатор или виртуальная машина для выполнения. В какой код LLVM компилипуются Они front-end компилятором - lang to LLVM assembly(Это загадка). Или же фронт-енд компилятор добавляет в бинанрник для них урезаный интепритатор или виртуальную машину.