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".
-
Pavel TišnovskýZlatý podporovatelDí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/
-
-
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). -
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ý podporovatel
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)
-
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ří.
-
> 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?
-
Pavel TišnovskýZlatý podporovatel
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. ...
-
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 :(
-
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):
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
ČLÁNKY DO MAILU