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

_>Интересно, а чем это глобально отличается от апплетов, которые 20 лет назад умели что-то подобное же

Идея буквально та же, а вот реализация на порядки лучше:

1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).
2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности).
3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов).

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

__>А теперь объясни, что это за сайтик такой с исходниками на расте, и в каком месте надо восхищаться.

Восхищаться надо тем, что этот сайтик целиком работает без использования богомерзких html/js/css. Т.е. не то, что он просто написан каким-то другим инструментом (типа GWT) и потом транслируется в html/js/css, а вообще тут таких сущностей нет в природе (ну не считая стандартной заглушки, грузящей wasm), даже прямо у тебя в браузере.

Т.e. я правильно понимаю, что backend и frontend написаны на одном единственном языке?

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

C>>Это крайне жирный подход, из-за которого сейчас уже примитивный список пары десятков комментариев еле ворочается на топовом железе.

B>Ну брешешь же.

Ты на тяжелой наркоте сидишь, что ли?

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

vsb>А так по сути то же самое. Только, вроде бы, реализованное получше и в правильном открытом виде.

Еще у апплетов была крупная проблема с версиями стандартных библиотек, которые устанавливались только как единый пакет на уровне системы, а скачать нужные библиотеки с сервера — ни-ни.

Здравствуйте, alex_public, Вы писали:
_>Восхищаться надо тем, что этот сайтик целиком работает без использования богомерзких html/js/css. Т.е. не то, что он просто написан каким-то другим инструментом (типа GWT) и потом транслируется в html/js/css, а вообще тут таких сущностей нет в природе (ну не считая стандартной заглушки, грузящей wasm), даже прямо у тебя в браузере.
*trollmode* А что если взять sciter и писать приложения с его помощью?

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

_>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).

На любых клонах Си.
Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
(только про Blazor не надо, там интерпретатор байткода из моно, без джита, в 50 раз медленнее обычного дотнета)

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

DM>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.

Я думаю, они сделают опциональный сборщик мусора на уровне VM.

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

__>Т.e. я правильно понимаю, что backend и frontend написаны на одном единственном языке?

Думаю да, но это тут не самое интересное. Такое можно было давно делать. И на JavaScript писать бэкэнд и кучу языков, например Java транслировать во фронтэнд. По-моему особого профита от такого подхода нет. Слишком мало общего кода между бэкэндом и фронтэндом.

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

DM>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей?

shadow stack

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

M>И тогда скорость работы и загрузки будет такая же, как у известных демок на Qt. Магии не существует.

Существует кеширование/переиспользование кода (библиотек).

DM> языки с GC пока не спешат компилиться в wasm.

Kotlin Native вполне себе может в WebAssembly. И там GC (а не просто ARC, как в Swift).

DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.

vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.

Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно.

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

_>>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).
DM>На любых клонах Си.
DM>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
DM>(только про Blazor не надо, там интерпретатор байткода из моно, без джита, в 50 раз медленнее обычного дотнета)

Про Blazor ничего не знаю (хотя какая связь gc и jit непонятно), а вот например Питон без проблем работает в wasm: https://github.com/iodide-project/pyodide. Вот https://alpha.iodide.io/notebooks/300/ живая демка научного блокнотика, исполняемого прямо в браузере. Более того, они там прикрутили уже и работу с DOM (понятное дело, что пока оно внутри работает через вызовы JS).

M>>И тогда скорость работы и загрузки будет такая же, как у известных демок на Qt. Магии не существует.
V>Существует кеширование/переиспользование кода (библиотек).

Оно и сейчас «существует». Как видно, особо не помогает.

В частности, из-за cache partitioning: https://www.bleepingcomputer.com/news/security/chrome-to-add-http-cache-partitioning-to-block-attacks-tracking/ и https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd-party-resources/

DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.

Каждый раз практически в любых разговорах про WebAssembly поражает насколько нихера люди не знают про предмет обсуждения. Не только на РСДН, кстати.

Роадмап: https://webassembly.org/docs/future-features/ в нем issue номер 16: https://github.com/WebAssembly/proposals/issues/16

Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC (это так же причина, почему в wasm'е нет доступа к DOM'у и нормальной интеграции с JS). Дотнетовский Blazor, компилирующийся в wasm, сначала грузит в браузер половину реализации дотнета, включая GC, а потом грузит приложения. Понятно, что никому это даром не надо.

M>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC

Но зачем они все нужны, если есть Gnome?

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

M>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC

Здесь то ли не хватает слов, то ли наоборот есть лишние. Меня всегда поражает, насколько люди нихера не могут выразить свои мысли, а потом негодуют, что их не поняли.

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

_>Идея буквально та же, а вот реализация на порядки лучше:

_>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).
_>2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности).
_>3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов).

И чтобы принять необходимость этого, договориться и начать что-то делать в этом направлении понадобилось 20 лет

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

Ops>И чтобы принять необходимость этого, договориться и начать что-то делать в этом направлении понадобилось 20 лет

Как говорится, верблюд — это лошадь, спроектированная комитетом