Vlákno názorů k článku Pohled pod kapotu formátu WebAssembly: nízkoúrovňová náhrada JavaScriptu od atarist - O Wasmu jsem kdysi, když nastoupil, myslel, že...
-
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 :-)
-
Filip JirsákStříbrný podporovatelOno 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.
-
Filip JirsákStříbrný podporovatel
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
-
Filip JirsákStříbrný podporovatel
Ano, ale Figma je přesně ten případ, kdy to nevadí – je to prostě aplikace, která akorát shodou okolností běží ve webovém prohlížeči. Dříve ti samí uživatelé startovali Photoshop a později Sketch, takže na to, že musí po zapnutí aplikace chvilku počkat, jsou zvyklí.
-
Já si s tím hrál jen malinko, pro nějaké experimentální demo.
On takový build SDL3+ImGui+apka zabere asi 4MB. Qt/QML už zabere nějakých zhruba 40MB a ještě navíc to člověk musí slinkovat staticky, čímž okamžitě poruší LGPL licenci a musí k apce uvolnit zdrojové kódy nebo v případě Qt tvrdě zaplatit komerční licenci. A dělat opensource webovou apku trochu postrádá smysl, když si to můžu přeložit na desktop jako nativní a poběží 2-3x rychleji a může sežrat víc paměti (zhruba, on ten bytecode běží překvapivě rychle, nevím jestli má nějaký just-in-time compiler). -
radekmStříbrný podporovatel
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.
-
radekmStříbrný podporovatel
> 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.
-
radekmStříbrný podporovatel
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.
-
Pavel TišnovskýZlatý podporovateljj 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)
-
Pavel TišnovskýZlatý podporovatel
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 :-)
-
Jednou věcí je něco, s čím pracujete denně a druhou aplikace, se kterými nepracujete denně. Nechtějte vědět, co dělá desetina sekundy třeba s konverzním poměrem v e-shopech. To je právě to. Navíc stejně, jako můžete špatně napsat desktopovou aplikaci, můžete špatně napsat webovou aplikaci a stejně tak můžete napsat obojí dobře.
Ostatně proč asi myslíte, že ve webové infrastruktuře a frameworcích existuje tak silná podpora k líné evaluaci víceméně všeho? A proč myslíte, že se velké monolitické balíky už dlouho na webu příliš nepoužívají? Proč myslíte, že se celé WASM používá i po těch letech velmi málo i když by člověk čekal, že po něm svět už dávno skočí?
Těch důvodů je dost ale ona ta nika uživatelů jako vy -- a máte to společné s velkou částí čtenářů tohoto serveru což naprosto chápu -- je reálně relativně malá.
12. 11. 2025, 09:27 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
? Proč myslíte, že se celé WASM používá i po těch letech velmi málo i když by člověk čekal, že po něm svět už dávno skočí?
Já bych to tedy nečekal. Na WASM je ještě spousta práce, než bude dávat smysl pro větší množství aplikací.WASM fandím; jsem rád, že to bylo navrženo a postupně to vzniká. Ale jak už jsem psal jinde, je to běh na dlouhou trať a aktuálně je použití poměrně omezené. Ale je vidět, že se to posouvá dopředu – před pár lety dávalo WASM smysl jen pro experimenty a nebo ve výjimečném případě, kdy by bylo potřeba spustit z prohlížeče dlouhotrvající výpočetně náročnou úlohu, kterou by nedokázal JavaScript engine optimalizovat do zdrojového kódu. Dnes už jsme podstatně dál a začíná to dávat smysl i pro běžné aplikace, pokud dělají něco jiného než jen volání webových API.
-
Pavel TišnovskýZlatý podporovatel
Ale jasně, však naše diskuze s UI teamem na toto téma byly nekonečné (oni se tedy nazývají UX team, tak by měli chápat různé role v různých aplikacích).
Myslím, že asi oba chápeme tlak na jednu stranu zobrazit co nejvíc dat s co nejmenším datovým tokem, na stranu druhou nabídnout nějakou rozumnou UX. WASM určitě nenahradí dejme tomu technologii, na které běží Root (IInfo), i když tedy UX by mohla být lepší i bez zdržení prvního načtení.
Ale v těžkotonážních aplikacích, kde je browser využívaný jako plocha pro nějaké sofistikovanější UI, tam to vidím jako dobrou technologii. A samozřejmě taktéž na aplikace, které jsou napsané v C/C++/Rustu/Go, tam transpilace do asm.js atd. sice možná je, ale moc objemu se tím neušetří.
-
radekmStříbrný podporovatel
> 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.
