Názory k článku Pohled pod kapotu formátu WebAssembly: nízkoúrovňová náhrada JavaScriptu

Ja by som len opravil chybu v clanku Blazor nepriklada C# do wasm, Blazor je SPA framework postaveny na wasm .NET runtime a JIT (ale pri builde dokaze prekladat C/C++ do wasm, dokze prekladat aj C# do wasm pomocou AOT kompilacii, ale to ma nevyhodu velkych binarok).

C# sa do wasm preklada pomocou "dotnet wasm workload".

Díky, pokusil jsem se to upravit. Je tedy asi zapotřebí nainstalovat wasm-tools?

Tu je vsetko zhrnute https://andrewlock.net/running-dotnet-in-the-browser-without-blazor/

díky, dneska to projdu (moc se světu .net nevěnuji, kromě F#)

O Wasmu jsem kdysi, když nastoupil, myslel, že do toho začnou překládat fakt velké projekty, ale zdá se, že to nenastalo. Spousta "velkých" věcí s prohlížečovou technologí (VSCode) je spíš TS/JS, než nějaké (dejme tomu) C# ve Wasmu. Ale research to používá - Jupyterlite například, což je Pyiodide. A potom šachové enginy a možná i bitcoinové minery, co běží na obskurních stránkách :-)

Ono WebAssembly pořád ještě ani zdaleka není hotové, teprve teď se teprve dostává nad úroveň assembleru. Třeba garbage collection je v Chrome dva roky, to je pořád dost málo na to, aby vznikly překladače, které už budou vestavěné GC používat a začalo se to používat v reálných aplikacích. No a pokud si runtime musel táhnout vlastní správu paměti, byla pak celá WASM aplikace pěkný bumbrlíček a vyplatilo se to jen v případě, kdy ta aplikace běžela dlouho a dělala náročné výpočty.

WebAssembly je běh na dlouhou trať a je dobře, že se do toho IT průmysl pustil, i když bylo od začátku jasné, že to začne být užitečné až za spoustu let.

zase pro C, C++, Rust stejně GC není potřeba. Jako je fakt, že lidi okolo Rustu WASM docela často zmiňují, tak se jich optám na nějaký demo aplikace.

Jistě, ale ta nika je zatím poměrně malá. Musíte mít aplikaci, kterou se vyplatí psát v C/C++/Rustu; potřebujete, aby běžela v prohlížeči; ale pro komunikaci s Web API stále potřebujete JavaScript.

Pokud vím, jediná široce rozšířená aplikace, která tohle splňuje, je Figma – nástroj pro UX designery, dneska průmyslový standard. Figma je psaná v C++.

Jinak třeba databáze SurrealDB psaná v Rustu také už umí běžet pod WebAssembly a dokonce umí data kromě in-memory ukládat i do IndexedDB v prohlížeči. To pro některé aplikace také může být zajímavé.

ESbuild (JS/TS bundler psaný v Go) je k dispozici také ve WASM verzi, což bude v budoucnu užitečné, že to nebude potřebovat vlastní binárku. Nicméně zatím je výrazně pomalejší, než nativní verze (svou roli v tom určitě hraje fakt, že Go je vysokoúrovňový jazyk, takže si do současného WASM musí přitáhnout celý runtime – tomu právě ty další vrstvy WASM pravděpodobně pomůžou).

Tj. postupně se začínají objevovat zajímavé věci (a vlastně samotná Figma už by stačila na to, aby WASM mělo své místo v historii jisté), ale je to prostě běh na dlouhou trať.

11. 11. 2025, 11:05 editováno autorem komentáře

Na druhou stranu, i ta Figma je v tom WebAssembly nechutně těžká váha. Při spuštění se stáhne několik desítek mega (!) z čehož podstatnou část tvoří wasm blob.

Těch aplikací je hromada. Třeba herní enginy Unity a Unreal umí exportovat do WebAssembly. Ale je to s různými omezeními.

Pak některé UI frameworky v Rustu (např. egui) a Zigu (např. DVUI). Demo v prohlížeči mají i na stránce.

Já si v Rustu dost oblíbil kombinaci WASM + egui pro různé grafické blbůstky, u kterých chci aby si je lidi mohli snadno pustit bez instalace. Takovéhle věci se v tom dělají hrozně jednoduše.

https://dvtomas.gitlab.io/color-mixer/

Narážím na tuhle chybu častěji:

The app has crashed. See the developer console for details.

F12 ->
panicked at src/main.rs:107:21:
Failed to start eframe: JsValue("WebGL isn't supported")

> No a pokud si runtime musel táhnout vlastní správu paměti, byla pak celá WASM aplikace pěkný bumbrlíček

Třeba Go nemá zas tak velký GC - celý runtime bude do 1 MB. Navíc dnešní stránky, kam lidé chodí, mají nekomprimovanou velikost desítky MB.

Ano, ovšem většina z toho jsou binární soubory v podobě obrázků. A jsou často velmi lazy; dotahují se do značné míry podle potřeby.

To mi nepřijde. Třeba na CNN s blokátorem reklam se mi stáhlo 53 MB a obrázků je z toho necelých 6 MB. Nejvíce zabírá JavaScript s přehrávačem videí boltPlayer (8 MB) a pak samotná HTML stránka (5 MB). Následuje JavaScript s UI (4 MB).

Navíc ten GC byste dost možná také mohl stáhnout později... Prostě by to chvíli nic neuklízelo.

jj někdy jsou ty WASM hodně velké, ale cachuje se to a stahuje jen jednou. Třeba takový https://jupyter.org/try-jupyter/lab/ si poprvé taky postahuje celej Python + velké knihovny (Numpy, Scikit-Learn atd.), to klidně minutu trvá. Ale potom se to startuje vlastně ihned, takže asi to není tak problematické (pro někoho, kdo si to ráno pustí a potom v tom celej den dělá).

(nakonec je to lepší, než klasické distribuované webovky)

No nevím. Tvrdit, že je to lepší, než klasické distribuované webovky mi přijde jako hodně odvážné tvrzení. Já bych z uživatelského hlediska tedy řekl pravý opak.

11. 11. 2025, 21:12 editováno autorem komentáře

Tak to se asi neshodneme (což je v pořádku). Webové aplikace, se kterými musím každý den pracovat, jsou všechny dost hrůza, hlavně v případech, že existuje něco podobného v desktopovém provedení. gcoc (jako celek), Jira (asi extrém v nedotaženosti UX), i ten GH pořád dotahuje spoustu dat (a tím pádem pomalu, UX dost špatná). Nakonec mít jednou stažený Wasm (a dělat sync na pozadí, pokud je to vůbec nutné) je z mého pohledu uživatelsky přívětivější. Ale chápu, že každý to vidí jinak - a záleží na konkrétních aplikacích. Třeba někde existují dobře udělané distribuované webovky :-)

> Spousta "velkých" věcí s prohlížečovou technologí (VSCode) je spíš TS/JS, než nějaké (dejme tomu) C# ve Wasmu.

Problém WebAssembly je v tom, že momentálně z něj nejde volat většinu API prohlížeče přímo a musí se to volat přes JavaScript. Takže JavaScript v nějaké formě tam být stejně musí.

Jinak už několik let překládám aplikaci v F# v Avalonii do WebAssembly a funguje to. Nicméně bohužel z prohlížeče nejde otevírat libovolné TCP spojení, takže jsem nemohl použít úplně stejný kód jako pro desktopovou verzi.

Navíc z výkonostních důvodů jsem u většiny aplikací přešel z F# + Avalonia na C3 + ImGui nebo Rust + egui + egui_taffy.

Ve WASM mi chybí kryptografické funkce/instrukce. Hlavně AES případně SHA-1/SHA-256. Nebo GCM. Téměř každá architektura dnešních CPU na které WASM cílí má nějakou formu HW akcelerace pro kryptografii. Dělat crypto ve webovém browseru v JS je obecně peklo, například window.crypto­.subtle se chvástá tím jak je low level a přitom ani neumí streaming digest. To udělali naschvál tak špatně, nebo to jsou "jenom" diletanti?

to je pravda. Ono je to ale těžký, například než byly vyspecifikovány vektorové instrukce (ty WASM umí, 128bitové floaty), tak přišly SIMD s 256bitovými a 512bitovými registry a WASM je zase vzadu. A dalo by se pokračovat - bf16, float16 pro AI atd. ...

Problém je, že to musí fungovať na všetkých architektúrach, nie len na x86_64. Nerobia to ani naschvál, ani nie sú diletanti. Podľa mňa to časom bude, tak isto ako v Jave nebolo všetko hneď.

Možná teď mícháme dvě věci dohromady. Všechny architektury: Jasně, chápu. ALE jak AES, tak SHA-1 (a SHA-256) jsou standardy psané anglicky. Jsou často a všude používané, dokonce tak, že některé (ne všechny) CPU architektury mají pro ně speciální HW instrukce / akcelerátory. Na WASM se můžeme dívat jako na další CPU architekturu a mohlo by to tam být. Nemuselo, ale mohlo. Na podkladové CPU architektuře, kde to není, by to stále fungovalo korektně. A rychleji, než to prgat po jednotlivých WASM instrukcích. Podobně jako garbage collection. Můžeš si ho napsat sám j jazyce, který kompiluješ do WASM, nebo to nechat na browseru (WASM VM) samotném, protože ten to stejnak už umí kvůli JS. GC ve WASM zatím nemáme, ale brzy budeme mít. (Na WASM se můžeme dívat jako na run time prostředí.) Stejně tak AES i SHA browser dnes také již umí kvůli HTTPS.

Za druhé streaming digest. Naprosté diletantství na straně tvůrců JS (nikoli WASM). Je to novinka v browserech pro tvůrce JS aplikací. Na stránkách Mozilla developers jsou všude veliké červené vykřičníky jak je to low level a advanced a tak. ALE abys spočítal digest z nějakých dat, tak ta data musíš mít VŠECHNA najednou současně v RAM. To snad ne. Neumožňují ti si držet nějaký stav a postupně do něj sypat data tak, jak ti pomalu postupně přicházejí po síti. Vždyť je to nějakých ±128 bajtů stavu. Zase, je to popsané v příslušném standardu NIST FIPS 180-4 a NIST FIPS 202.

WASM nie je ASM ale bytecode. Davat don vsteky specialne alternativy instukcii pre procesory nie je dobry napad.

Napriklad .NET to riesi cez inhristics, a teda namiesto spcielnej instrukcie volam specialnu funkciu, ktoru prelozi JIT bud na SIMD/AES instrukciu procesora, ked ju procesor ma, alebo pouzije fallback.

Ale suhlasim s tym, ze crypto JS APi navrhli diletatnti a pouzivat akukolvek kryptografiu v browseri nie je moc dobry napad (povedzme este ten hash hej, ale sifrovat to je uz dvojsecna zbran).

Myslím, že aj ten sandboxing vo web assebly zohráva úlohu, to obmedzuje použitie rôznych intelových vychytávok + intel je kitchensing architektúra. Je to potrebné spraviť tak, aby to bolo bezpečné (nevravím o vašej kryptografiu), multiplatformné a ešte to musí bežať aj na serveri aj v prehliadači rovnako. Ja si nemyslím, že sú diletanti, alebo že chcú škodiť, len ten projekt musí splniť niekoľko obmedzení, tak im to proste trvá.

Komu sa to nepáči, ten môže ísť na lampáreň, asi tak :(

A v tom pripade by nebolo lepsie pouzit tu Javu hned?

Tipujem, že predrečník je obmedzený na javascript/we­bassembly v browseri. Ináč by samozrejme asi použil niečo iné.

Nejsou to diletantni? No, já teda v JS píšu už hodně let ale čím déle, tím víc si tím nejsem jist. Nemá cenu si něco nalhávat: mnoho standardních API je příšerných a nemá to jen historické důvody.

Vytvorenie štandardného API je umenie možného, nie je cieľom uspokojiť expertov z diskusie root.cz.

Ty experty to pak jenom živí, že... Všiml jste si, že to API má sloužit primárně jim?

Někdo se mně ptal, jesli Brány Skeldalu nebudou v prohlížeči. Pořád mám průzkům Wasm v backlogu, ale holt mám toho hodně, snad se k tomu někdy dostanu :)

pri preklade z go, je wasm aj sviznejsie ako vysledne js (gopherjs)... a pri jednoduchych projektoch sa da pouzit aj tinygo, to produkuje este mensie vystupy...

mozete porovnat js, wasm a tinygo wasm verziu toho isteho projektu (dal som tak dlhe linky preto, lebo na nich je vidno rozdiel v rychlosti medzi js a wasm pri nacitavani hry a urobeni/vrateni tahu):

JS (1.4M):
https://jezek.github.io/URLchess/index.js.html#LbzjGV6lEL-tMUtcLM1tBQwoVfleNV8nOWeVfVcWMOWHOH0kKakcFMcVMVnlVjyqjV9QUclzaizbDKbiKRiZRKZaKDaTDEQZEN79HFZiNO5zFTzkTSiwSZqiZx85xowpohiaVMpbhj57js46slaSJSbSABkuCQ9-Ma-_Q0ufOFfl07lUFMUa70_-IYSkPf64Bx4YxzYIMTIL

WASM (3.4M + 17K):
https://jezek.github.io/URLchess/index.wasm.html#LbzjGV6lEL-tMUtcLM1tBQwoVfleNV8nOWeVfVcWMOWHOH0kKakcFMcVMVnlVjyqjV9QUclzaizbDKbiKRiZRKZaKDaTDEQZEN79HFZiNO5zFTzkTSiwSZqiZx85xowpohiaVMpbhj57js46slaSJSbSABkuCQ9-Ma-_Q0ufOFfl07lUFMUa70_-IYSkPf64Bx4YxzYIMTIL

WASM TinyGo (1,5M + 16K):
https://jezek.github.io/URLchess/index.tinygo.wasm.html#LbzjGV6lEL-tMUtcLM1tBQwoVfleNV8nOWeVfVcWMOWHOH0kKakcFMcVMVnlVjyqjV9QUclzaizbDKbiKRiZRKZaKDaTDEQZEN79HFZiNO5zFTzkTSiwSZqiZx85xowpohiaVMpbhj57js46slaSJSbSABkuCQ9-Ma-_Q0ufOFfl07lUFMUa70_-IYSkPf64Bx4YxzYIMTIL

poznamka: prve nacitavanie moze trvat dlho, lebo stahuje .js/.wasm subory, druhe otvorenie/obnovenie stranky uz bere subory z cache, tak by to malo byt rychlejsie