Vlákno názorů k článku
Video z workshopu WebAssembly - Začátek konce éry JavaScriptu? od oss - Este co sa tyka chabjucich vlastnisti WASM. - GC...

Este co sa tyka chabjucich vlastnisti WASM.

- GC - ten naozaj nie je treba s skomplikoval by sa tym preklad napriklad C-ecka, alebo Rustu. WebAssembly ma byt webovy assembler, nie webovy javascript.

- WASM nevie spustit blok vlastnej pamete, co je bezecnostna vec, ale sucasne to zabranuje v nom implementovat JIT a kod sa musi interpretovat - Je to zle, alebo dobre? Neviem sa rozhodnut.

- Chybajuci pristup k DOM - toto je podla mna vec, ktora webassembly taha k zemi a zabranuje jeho rozsireniu, lebo aj tak clovek musi pisat javascript. Pricom by napriklad WASI tuto vec uz vedelo vyriesit.

Javascript a WASM se nenahrazují, ale mají se doplňovat.

Snažit se udělat z WASM náhradu javascriptu je odcházení od toho, jak a proč byl WASM navržený. Jako doplněk k javascriptu, aby bylo možné implementovat výpočetně náročné operace rychleji.

Je potřeba GC nebo přístup k DOM? Fajn. Od toho je tu javascript.

Chceme rychlou kompresi/dekompresi ZSTD? Zavoláme funkci WASM.

Nechci dělat v javascriptu? Fajn. Neměl bych se pouštět do webových aplikaci.

Ja prave GC nechcem vo webassembly tam je to zbytocne. Ale pristup k DOM-u a senzorom ano, lebo je to technologicky vyriesitelny problem (spominane WASI). Takze nechapem, preco tvorcovia prehliadacov WebAssembly takto sabotuju.

> Je potřeba GC nebo přístup k DOM? Fajn. Od toho je tu javascript.
Javascript bol vymsleny na jemne skriptovanie, nie na pisanie rozsiahlych aplikacii. Ked sa na to pouziva, tak preco neopravt Wasm, tak aby bol pouzitelny? A prisniest do browseroveho vyvoja slobodu?

"Javascript a WASM se nenahrazují, ale mají se doplňovat."

To se ale pletes. Cely je to ciste a vyhradne o tom, abys nemoh snadno z js vykopnout prostrednicvim nejakeho adblocku to, co nechces. Delat totez z bajtokodu je o poznani narocnejsi.

Napríklad wasmtime umožňuje AOT kompiláciu, takže nie je celkom pravda, že je to interpretované.

AOT je nieco ine ako JIT.

To je, ale aký máte konkrétne problém, ktorý by JIT riešila a AOT nie?

Ako pisal kolega - nejde vo WASM spravit vykony interpreter jazyka, a je jedno, ci je to .Net, Lua, PHP, a neviem este co...

Napriklad Blazor to musi obchadzat tak, ze IL neinterpretuje iba po instrukciach, ale ma sadu casto pouzivanyhc blokov. Sice Blazor podporuje naplno AOT, ale vysledne "binarky" vo WASM su desatnasobne vetsie ako .NET IL. Podobne to bude s akymkolvek jazykom.

Ono vo vysledku, aj tak viac zdrzuje pristup k DOM-u, lebo ten jazyk musi ist cez minimalne 3 zbytocne vrstvy.

Já ti námitku pochopil tak, že nelze udělat JIT v rámci WASM, tedy že třeba PHP engine zkompilovaný do WASM nemůže použít JIT.

> WASM nevie spustit blok vlastnej pamete, co je bezecnostna vec

IMHO důvod bude ve zjednodušení implementace a paradoxně i ve výkonu. Kdyby bylo možné přepisovat WASM kód libovolně za běhu, bylo by mnohem těžší wasm kompilovat do nativního kódu. Udělat dynamické načítání kódu lze i bez toho (kód by nešlo jen tak libovolně měnit za běhu, aby se JIT neměnil pod rukama), ale asi to nebyla priorita.