Názory k článku
Video z workshopu WebAssembly - Začátek konce éry JavaScriptu?

no a za chvilu sa vratime oklukov k nativnym aplikaciam na desktope. Akurat ze tentoraz budu distribuovane a instalovane cez browser. Fakt super .....

Obrovská výhoda je MultiPlatformnost protože Operační Systém je Web.

Shrnuto, multiplatformní povaha WebAssembly umožňuje vývojářům vytvářet vysoce výkonné aplikace, které mohou běžet na různých zařízeních a v různých prostředích, což z něj činí mocný nástroj pro moderní webový vývoj.

Jednou z klíčových vlastností WebAssembly je jeho multiplatformní schopnost, kterou lze chápat několika způsoby:

Kompatibilita mezi prohlížeči: WebAssembly je podporováno všemi hlavními webovými prohlížeči (Chrome, Firefox, Safari, Edge), což umožňuje vývojářům psát kód, který běží konzistentně v různých prostředích, aniž by se museli obávat specifických implementací prohlížečů.
Jazyková nezávislost: Ačkoli je WebAssembly často spojováno s jazyky jako C a C++, může být kompilováno z mnoha jazyků, včetně Rustu, Go a dalších. To znamená, že vývojáři mohou používat své oblíbené programovací jazyky k vytváření aplikací, které běží v prohlížeči.
Výkon: WebAssembly je navrženo jako nízkoúrovňový bajtkód, který může být rychle vykonáván JavaScriptovým enginem prohlížeče. Tato výkonnostní výhoda jej činí vhodným pro aplikace, které vyžadují vysokou výpočetní sílu, jako jsou hry, simulace a zpracování obrázků.
Přenositelnost: Moduly WebAssembly mohou být spuštěny v různých prostředích mimo webový prohlížeč, včetně serverových aplikací (pomocí runtime jako Wasmtime nebo Wasmer) a vestavěných systémů. Tato přenositelnost umožňuje vývojářům používat stejný kódový základ napříč různými platformami.
Interoperabilita s JavaScriptem: WebAssembly může pracovat vedle JavaScriptu, což umožňuje vývojářům využívat existující JavaScriptové knihovny a frameworky, zatímco také využívají výhod výkonnosti WebAssembly pro úkoly náročné na výpočet.
Bezpečnost: WebAssembly běží v bezpečném, sandboxovaném prostředí, což pomáhá chránit hostitelský systém před škodlivým kódem. Tento bezpečnostní model je zásadní pro spouštění nedůvěryhodného kódu v prohlížeči.

Až tak vysokovýkonné to nie je, oproti natívnej jednovláknovej aplikácii v Rust, mi tá istá aplikácia bežala 5 krát pomalšie vo webassembly. To sa len načítal vstup, prebehlo parsovanie, vypísal sa výstup. Stále 4 krát rýchlejšie, než taká istá aplikácia v pythone.

Neberte to prosím ako smerodajné a ultimátnu pravdu, ale IMHO je vhodné do webassembly kompilovať len veci, ktorým nevadí, že sú 5 krát pomalšie.

Zajimavé. ChatGPT nebo Claude?

Nešlo by v pravidlech diskuze zakázat pastování traktátů z AI?

Ako to rozoznáš od toho, či to je bežný používateľ píšuci bláboly, alebo AI? Jedine ak má tam ten príznak že "zlatý podporovateľ", alebo tak, vtedy človek vie, že ide o humanoida a nie je to generované.

Možná by stačilo omezit délku příspěvku. Kromě pár kvalitních psavců skoro všechny dlouhé příspěvky píšou nezkrotní grafomani. To AI je někdy i příjemnější.

Blbě. Ale styl třeba ChatGPT se přeci jen nezapře.

To tu uz raz bolo, napriklad taka Java a vidime ako to dopadlo. Multiplatformnost je take zaklinadlo ktore ma lakat ale prakticky to nikdy poriadne nefunguje. A kompatibilita je len do momentu kedy niektory z vyrobcov browserov zaciti moznost sa presadit a vymysli svoju extra tuti fruty featuru ktora bude iba v jeho browsery (ms - edege alebo google chrome ale aj ostatny).

To je šokantné, že sa používajú virtuálne stroje.

No nevím...

Můj dojem z přednášky je, že pán zavrhl Webassembly protože dle mého vůbec nepochopil co to je.

Nejdříve se dozvíme, že Wasm je hrozně omezené, že nemá objekty a vůbec je to omezený jazyk (facepalm) ... je to web ASSEMBler nízká ůroveň programování (o 10 pater pod jeho milovaným PHP)

Wasm je pomalé, protože místo ,aby si zkompiloval PHP kód do wasm, tak si zkompiloval PHP engine a v něm interpretoval PHP ... (facepalm)

A dále je Wasm špatné protože Unreal engine ukončil podporu ... to že Unity v něm běží jak z praku tak prohodí jen tak mimochodem ...

A vůbec je špatné, že se musí kód kompilovat ...

Bylo utrpení to dokoukat.

občas si na jejich workshopy také zajdu, ale mlčím a jen tiše sleduji. Jsou to php/js weboví vývojáří a jejich cílovka jsou asi zase weboví vývojáří.

Je skvělý, že má někdo odvahu si něco připravit a jít to ostatním říct, je skvělé, že se o ty věci zajímají, někdy mají dobré postřehy, je dobré občas vidět lidi z podobného oboru a pokecat.

Je to dobrý pohled jak vlastně vypadají běžní vývojáři, jak problémy řeší, jak jsou schopní si téma nastudovat a prokousat se s ním. Pro mě to je velmi užitečné, protože posledních 20 let jako vývojář už nepracuji a nemám moc příležitostí vidět jinou bublinu. Je pak snadné říct, že "je utrpení to dokoukat", ale každý se věnuje prostě něčemu jinému a ne každý má ve všem hluboké dobře prezentované znalosti. Jak by vypadala tvoje přednáška, když bys měl mluvit o něčem, co právě zkoumáš a je to lehce mimo tvůj obor?

Ta cílovka je jiná, já bych to tolik nekritizoval, aspoň ne veřejně, ale pouze osobně do očí jako zpětnou vazbu autorovi.

Autor tu! Osobně bych byl rád za tu zpětnou osobně do očí. Příležitost bude už příští týden (nebo zítra 14.5.), anebo můžeme zajít jen tak na pivo. Nechám to na vás...

tenhle týden jsem mimo dosah Plzně, v příštím týdnu tam ale cestu mít mohu, na pivko rád zajdu a rád poskytnu zpětnou vazbu

Super! Tady je rovnou jedna příležitost - 21. 5. 2025 budu na workshopu „Efektivní využití AI agentů ve vývoji“ v Osteria Garage (Plzeň Slovany) od 18:00. Nebudu přednášet, takže budeme mít spoustu času to probrat. To samozřejmě platí pro všechny, kdo si o tom chtějí osobně popovídat. Je škoda na sebe štěkat v diskuzi na Rootu.

Kritik-tu!

Obávám se, že to asi osobně nepůjde. Plzeň je z ČB dlouhé hodiny daleko ...

Doufám že si ten názor neberete moc osobně. Uznávám že jsem si poslední větu mohl odpustit. Za zbytkem si, ale stojím.

Celá přednáška mi připoměla dávnou přednášku kde byl kritizován Debian v roli serveru. Přednášejíci - milovník Windows - dospěl k názoru, že Debian server je na nic protože nemá GUI. Úplně minul cíl, důvod a účel.

Dle mého názoru byste si z této kritiky mohl vzít ponaučení, třeba to pomůže vašim dalším přednáškám.

Na začátek jen malé upozornění - moje komentáře procházejí moderací, takže se tu můžou zobrazovat se zpožděním nebo v jiném pořadí. Není to ignorance.

Nic si neberu osobně, naopak, máte moji plnou pozornost. A mým největším cílem teď je vytěžit z Vaší zpětné vazby co nejvíc konkrétních poznámek, abych se mohl zlepšit. Přece jen, když napíšete „přednáška o tématu, kterému úplně nerozumí“, tak mi to bohužel moc nepomůže. Neboť bez konkrétních bodů se z toho těžko poučím.

Přijde mi, že za zklamáním tu je špatně nastavené očekávání. Už to, že to nemá GC, znamená buď použít jazyk bez GC, nebo k tomu nějaký GC zkompilovat do webassembly a přibalit. V takových situacích ale dost možná vyjdou lépe nějaké transpilery.

Reálně jsem wasm použil jako programátor asi třikrát. Z toho dvakrát jsem použil hotový software zkompilovaný do wasm (LaTeX a Stockfish). Naposledy jsem si zkusil udělat GUI ke kódu v Rustu, tam použití wasm bylo ovlivněno tím, že jsem si to chtěl vyzkoušet.

Nejhorší co může přednášející udělat, je přednáška o tématu kterému úplně nerozumí. Na takové téma se dělají diskuse, workshopy nebo jiné kooperativní akce.

BTW: nemám dost kuráže abych mohl prohlásit, že nějakému tématu rozumím tak abych o něm mohl přednášet. Takže přednáška odemne nebude...

A ještě horší je, pokud tomu rozumí, ale neumí to podat srozumitelně. V tomto případě mi přednáška připadá dobrá, jen stačilo upozornit na několik problémů. Psát wasm vůbec není potřeba a každý jazyk to umí naprogramovat sám. Takže i golang "běží" ve wasm. Kód pro server a klienta stačí psát v golangu.

To je pravda - nakonec jsem nepoužil přibližne 40 slajdů. Mne to vždycky tak mrzí, že ta přednáška třeba nemůže být 4 hodinová. :-/ Je tu ale ještě druhá věc - většina publika nepoužíva Go, takže by to pro ně mohla být překážka.

Máte nějaké praktické zkušenosti s Go ve webassembly? Pokud ano, nechcete se podělit?

Předem chci neironicky poděkovat, že jste to dokoukal. Já osobně bych asi něco, co mi způsobuje utrpení, nedokoukal – takže za to máte můj velký respekt.

K jednotlivým bodům:

PHP zrovna nepatří mezi mé milované jazyky. Upřímně si ani nemyslím, že je zdravé milovat jakýkoliv programovací jazyk – ale to už je spíš na filozofickou debatu u piva. Každopádně v přednášce o WebAssembly a webu se PHP zmínit muselo – je to pořád jeden z nejpoužívanějších jazyků na backendu.

Kompilace PHP přímo do WebAssembly zní jako zajímavý nápad, ale zatím neexistuje žádný reálně použitelný nástroj, který by to zvládl. A vlastně si ani nemyslím, že by většinu lidí takový nástroj potěšil – PHP je dost kontroverzní i bez toho. Ale stejné problémy byste měli i s Pythonem, Ruby, Lua… Zkrátka se tam potýkáme s dynamickým typováním, evalem a nutností přibalit runtime.

A jak funguje Blazor (.NET ve Wasm)? No… to možná člověk vlastně ani nechce vědět. Ani Mono si tohle nezasloužilo.

WebAssembly je podle mě takový kočkopes – měl to být nízkoúrovňový sandboxovaný bytecode s téměř native performance… ale najednou tu máme výjimky, GC, JS Promise integraci, a WASI component model, který na mě osobně působí dost "CORBA like". A cokoliv co vypadá jako CORBA mne hodně děsí. :-D

Unreal Engine jsem zmínil právě proto, že byl často uváděn jako vlajkový use-case. Když z WebAssembly vycouval byl to důležitý signál. Chápu, že to není všeříkající, ale myslím, že to ilustruje mezeru mezi očekáváním a realitou. Je to jako kdybyste postavil závodní okruh pro Formuli 1 – a zjistil, že jezdí hlavně traktory. Super, ale asi jste čekal něco jiného.

A k tomu závěrečnému bodu: mohl byste mi prosím upřesnit, kde konkrétně podle vás tvrdím, že „kompilace je špatná“? Neříkám, že to nezaznělo, ale opravdu mě zajímá, co vás k tomu dojmu vedlo. Pokud to tam zaznělo necitlivě nebo nešťastně formulované, rád si na to posvítím.

O víkendu jsem koukal na jiný jejich záznam o překvapení v různých jazycích. Bohužel není vidět tabule, takže se toho člověk moc nedozví.

Dobrý den, na onom workshopu nám bohužel selhala technika, tak záznam plátna chybí. Ale v popisku videa na YT je odkaz na GitHub, kde je prezentace k dispozici. Není to sice ideální, ale aspoň něco...

O víkendu jsem dal dohromady malý projekt: ateska.github­.io/warlords, jako součást mého retro-gaming / preservation úsilí. A zároveň jako příležitost, jak si (znovu po čase) osahat WebAssembly a jeho propojení s Go.

Musím říct, že jsem byl příjemně překvapen — jak rychlostí vývoje, tak i výkonem běžící aplikace. Go se do WebAssembly překládá přímočaře, a práce s HTML5 Canvasem přes JS bindings je svižná a dobře použitelná.

WebAssembly na mě působí jako velmi schopná technologie s obrovským potenciálem. Jen mě mrzí, že se zatím nestala mainstreamem — škoda, mohla by být základem pro moderní webové aplikace s nativním výkonem.

Souhlasím s tím, co zaznělo na zmíněném workshopu: WebAssembly má své výzvy, ale já osobně zůstávám optimistou.

Co je to, prosím, ta "moderní webová aplikace": A co je to, prosím, přesně ten "nativní výkon"?

To neznas? To je stranka na ktery se ti bez sciptovani nezobrazi ani hlaska ze si mas povolit sciptovani. Vsechno se animuje, vysouva, zasouva, a na monitoru to vypada tak, ze z tech 1920px se pouziva tech 600(a to mas kliku) nekde uprostred, pismena maji vejsku nejmin 10em, a mezery mezi nejmin 20. Takze se ti na obrazovku vejde tak 5 radku textu.

Nativni vykon je pak to, ze kdyz nemas aspon 100+Mbit konektivity, nacita se to 5 minut, sezere ti to klidne 30+jader CPU na 100% a kdyz se podivas na obsazenou ramku, tak te trefi, protoze tomu ani 10GB nestaci.

A typicka ukazka je treba youtube. K popukani je pak to, ze to nefunguje ani v jejich vlastnim browseru. O to vic, ze kdyz to bylo ve flashi, tak tomu stacil o 3 rady pomalejsi HW a fungovalo to uplne vpohode.

Moderní webová aplikace je dle mého názoru taková, ve které nemusím používat Javascript ale nějaký novější programovací jazyk. V Javascriptu píšu hodně a mam ho v podstatě rád, ale to stáří a technologický dluh z něho trčí už docela dost. V moderním vývoji bych čekal možnost volby jaký jazyk zvolit - tak, jak to je např. na desktopových operačních systémech.

Nativní výkon je takový výkon aplikace, který poskytuje přímo hardware, bez interpretu nebo VM atd. - případně něco tomu hodně blízké.

Ono je celkem zřejmě, že dříve či později něco takového vznikne - viz. obsah té přednášky. U Webassembly mě přijde, že to je uchopené ze správné strany ... a nepřál bych si, aby opět vznikly technologie uzavřené, typu Active-X nebo Flash.

Preboha preco ? Moderny jazyk kde, backend alebo frontend ? Asi je mysleny frontend ale preco sa vobec snazime vsetko tlacit do frontendu ? K comu je dobre z browseru robit druhy "desktop" ? Ja tomuto "modernemu" progressu nerozumiem. Znasilnovanie browseru na desktop pouzitie kde na konci je to po vsetkych strankach horsie ako klasicka nativna aplikacia, jedine ze je to distribuovane cez web. Nativny vykon nikdy nebude kedze web apka bude vzdy bezat v sandboxe browseru a ten bude z roznych bezpecnostnych dovodov do toho kecat. Skor by ma zaujimalo porovnanie ci je az tak produktivnejsi vyvoj napriklad React aplikacie oproti klasickemu desktopu (povedzme .net). Ked musim riesit npm a zavyslosti tak si zacinam s laskou spominat na javu a maven.

Ako iny aj ja mam k prednaske nejake vyhrady.

Pre mna bol WASM sposob ako sa do sveta borwserov priniest slobodu v tom, v com tvorit webove aplikacie.

Co sa tyka Blazor WASM, uz som v nom spravil cez 8 aplikacii a mozem z cistim svedomim povedat, ze s tou richlostou to nie je take zle, ani s velkostou, ked to nie je spustene s debugom, tak pouzivatel ani nevie, ze je na Blazor stranke (rozdiel medzi Reactom nezisti pokial sa nepozrie na zdrojaky), samozrejme 3D hra v tom bude pomala, ale bezna aplikacia, kde si pouzivatel klika je to OK. A hlavne ma netrpia javascript kniznice.

A ked uz chcete spustit PHP v browseri, preco na to neist fikanejsie? Zlate ceske rucicky vytvorili PeachPi https://www.peachpie.io/ - staci PHP skompilovat do .Net-u (podla blogov je vysledok vyrazne richlejsi a bezpenejsi ako standardne PHP - skusali to na Wordprese) a nasledne to pouzit v Blazor Wasm.

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.

Rust má dobrou podporu pro WebAssembly, tak když jsem si nedávno chtěl udělat aplikaci co poběží na desktopu i (hlavně na webu), byla to jasná volba. Bylo to vcelku přímočaré, výsledek pro zajímavost zde: https://dvtomas.gitlab.io/color-mixer/

Js om to kedysi s Rust a wasm skusal, ako fungovalo to, ale od pouzitelnosti pre realne aplikacie to malo este daleko.

Na 4k monitoru jsou ovládací prvky příliš malé. Monitor je 4K, 32", škálování mám 125%, Firefox.

Ma podporu webassembly, něco s tím lze dělat, ale má to i svá omezení. Zejména jsem narazil, když jsem chtěl více vláken. Se stabilním Rustem to nešlo.

Neviem ci vlakna v prehliadaci je to prave orechove.
Ja som v tom nieco skusal vyse rok dozadu a najviac mi vadilo asi to, ze niektore kniznice sa hrozne snazili spravit React, a ine boli len kniznice, na hranie dobre, ale celu aplikaciu sa mi s tym nechcelo babrat.

Vlákna v prohlížeči – jak na co. Na bežné GUI je to overkill (ale tam je často overkill celé WASM), zvlášť pokud samotný render necháme na prohlížeči. Ale na nějaké výpočty – šachový engine, práce s obrázky apod. mi to smysl dává.

A umí WASM vůbec multithreading? Myslel jsem, že zatím ne.

Aha, někde už asi jo: https://webassembly.org/features/

14. 5. 2025, 18:01 editováno autorem komentáře