Vlákno názorů k článku
Všechny velké prohlížeče už podporují WebAssembly
od Diskobolos - Proč zdejší skeptiky kamenujete? Nemusím mít přece znalosti...
-
Diskobolos (neregistrovaný)
Proč zdejší skeptiky kamenujete? Nemusím mít přece znalosti SW inženýra, abych věděl, že přidávání (složité) funkcionality vede k zanášení chyb a rizik do budoucna. Java a flash v browseru byly problémem po celou dobu své existence a taky na to dojely. Chyby a díry v jejich implementaci se řeší/využívají dodnes. A myslet si, že sandbox vše spasí je taky mýlka. Je to další vrstva, která může a bude obsahovat chyby/slabiny (tím spíš, že bude x implementací pro jednotlivé browsery). A co se týče souhlasů, to tu vůbec neřešme - znalý uživatel si to pohlídá a BFU všchno odklikne. Rozumějte, nikdo nebrojí proti pokroku. Když to ale nepřinese nic nového (tj. nic co by neuměl samotný JS), tak je to vzhledme k výše uvedenému napováženou. Můžeme diskutovat o výhodě rychlosti samotného vykonání kódu skriptu. Jenže kompilace samotného kódu JS vs běh bytekódu v sandboxu se dle mého +/- vyrovná - při běžném použití. Jestli ale někdo chce dělat obrovské (skoro nativní) aplikace v browseru (aby využil rychlost bytekódu), tak to nepochopil princip vývoje aplikací v prohlížeči (otevřte si taskmanager/ps a podívejte se na režii prohlížeče). Z mého pohledu tedy argument o rychlosti padá. Osobně tam nevidím žádný další zásadní benefit.
-
Alfonz (neregistrovaný)
Ten nejzasadnejsi benefit jsou HRY :-D Playstation 5 a XXXBoXXX budou jiste cloudove s minimalnim OS a bez disku (neco na styl AppleTV). A ty hry pobezi na forknutem chrome prave pres wasm. Jsou proste spousty kodu v C-cku ci jinych synchronnich jazycich a prepisovat je do asynchronniho JS nemusi byt vzdy jednoduche. A nac vubec, kdyz to staci skomiplovat pro "procesor" s "instrukcni sadou" wasm.
-
Diskobolos (neregistrovaný)
OK, v herním průmyslu se točí spoustu peněz a může to být argument. Na druhou stranu si myslím, že pro náročné hry není prohlížeč určen (možná že takový trend je, nevím). Tetris ano, Call of duty 5 rozhodně ne. Navíc přepsat existující kód Cčka nebude tak jednoduché, jak to prezentujete - specifický způsob práce s periferiemi (a jiné, např. omezení plynoucí ze sandboxu) budete muset přepsat do "wasm". To nebude žádná sranda.
-
Alfonz (neregistrovaný)
nejake demo abys videl ze wasm + webgl je pohoda:
https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html
a Unreal Engine 4 uz nejaky ten patek podporuje target wasm+webGL
https://www.bit-tech.net/news/gaming/pc/epic-unreal-engine-4-16/1/
-
Diskobolos (neregistrovaný)
To jsi mi dal, FF na 6GB RAM:
Downloading (32.15s) 125MB
Building shaders (15.49s)
Compiling WebAssembly...Btw webgl není diretx (když už jsme u toho snadného přepisování kódu v C). Ukázka pěkná, celé to pozadí odporné. Opravdu je tento typ úloh vhodný pro prohlížeč? Připadá mi to jako Boing 737 co má na zádech raketoplán Discovery na denních letech Paříž - Bombaj a zpět.
-
Proc by nebyl?
A zbavit se zavilosti na DX ti prijde spatne ? Jinak, OpenGL velke enginy samozrejme podporuji, migrace na WebGL je snadna (pokud uz ji neumi).Ale bral bych to pozitivne - aspon treba konecne dojde k rozsireni k Linuxu na desktopu, kdyz bude 99% aplikaci vc. her pro bezneho uzivatele v prohlizeci ;-)
-
To je blbost.
Nikdo to do JS prepisovat nebude, pouze pouzije Emscriptem k tomu, aby se existujici C/C++ prelozilo pomoci LLVM/clang do JS/wasm.
UT4 (jak uz bylo napsano) to podporuje velmi dlouho.
A FB uz od minuleho roku ma "Gameroom", ktery chce "konkurovat" Steamu jako herni platforma - vse samozrejme v prohlizeci.
Apple zase pripravuje WebGPU - API nad vulkan/opengl/direct3d prave pro pouziti z webu.Takze ano, toto je urcite budoucnost minimalne znacne casti her na PC platforme.
-
Konzole si myslim, ze to mine - tam je naopak cilem vyzdimat z HW posledni kapku vykonu vzhledem k tomu, ze konzole jsou obecne zarizeni s nizsim vykonem a dlouhym zivotnim cyklem - takze tam urcite nikdo nebude takto plytvat vykon.
Ale co se tyka PC gamingu - tak tam to urcite realna budoucnost je, zejmena na mensi / causaul hry, je to jednoznacne benefit a nejlepsi mozna platforma.
-
Ten benefit je v tom, ze se ostatni jazyky nebudou muset kompilovat do Javascriptu jako do ted, ale do k tomu primo navrzenymu bytecodu. Coz zjednodussi vyvoj prekladacu. Zadny negativa to nema, protoze Javascript zkopilovanej treba z Elmu nebo ClosureScriptu taky nema s puvodnima zdrojakama nic spolecnyho a cist to nebude o moc jednodussi nez ten dekompilovanej bytecode.
-
Diskobolos (neregistrovaný)
Překladače JS v prohlížečích tu už jsou a fungují dobře. Teorie formálních jazyků, překladače a interpretace udělaly ze skriptovacích jazyků plnohodnotné nástroje vývoje. Na určitý okruh problémů je to vhodný nástroj. Kdyby autoři řekli, že parsery/kompilátory JS dají pryč a nahradí bytekódem, tak budete mít pravdu. Navíc, lexikální/syntaktický analyzátor Vám (mimo jiné) zajišťují/hlídají validitu/strukturu JS skriptu. Jinými slovy, pustí Vás jen tam, kam budouch "chtít". To je v prostředí prohlížečů a internetu zásadní benefit. V bytekódu tohoto v takovém rozsahu nedocílíte - musíte mít sandbox.
-
Filip JirsákStříbrný podporovatelV bytekódu tohoto v takovém rozsahu nedocílíte - musíte mít sandbox.
Proč? Jaký je rozdíl v tom, jestli mám v textovém souboru napsánowhilenebo jestli mám ten samý význam zakódovaný v binárním souboru jako bajt07? Nevím, jak přesně wasm vypadá, ale nějak jsem nepostřehl, jak všichni ti odpůrci ve zdejší diskusi přišli na to, že wasm bude něco zásadně jiného, než JavaScript zapsaný v binární podobě. -
Nevím přesně, jak je to implementováno, ale spíš než přidávání složité funkcionality jde o přeskočení několika fází interpretru - parsování atd.
Samozřejmě je nutné ohlídat vstupy tak jako u všeho, ale to v principu není nijak složité. Sandbox už tam je tak jako tak, v tom se nic nemění. Rozdíl oproti javě a flashi je ten, že tenkrát to měly na starost firmy, které neměly bezpečnost tak ošetřenou a dodávalo se to jako binárka, prostě typický rozdíl mezi open a closed source. -
Diskobolos (neregistrovaný)
Argument o teoriích formálního zprac. jazyků o příspěvek výše. Myslet si, že programátoři Adobe/Oracle neřešili bezpečnost jinak, než vývojáři Google/Mozilla, je poněkud zcestné. Chyby se dělají i v OS. Ano, přijde se na ně třeba dříve, na druhou dáváte opravdu vynikajícím vývojářům se zápornou motivací nástroj pro hledání zadních vrátek. Věřte mi, že oni ty chyby najdou tam, kde průměrný OS vývojář nebude mít ani tušení. Podívejte se na security logy velkých OS projektů.
-
A ohledně kamenování - když někdo píše objektivně snadno vyvratitelné nesmysly, tak to prostě uvedu na pravou míru, stejně tak, když někdo používá pojmy jejichž význam nezná.
To že s novým kódem přijdou nové chyby nerozporuji, ale je to argument se kterým jsme to mohli zabalit u děrných štítků nebo ještě dříve. -
Diskobolos (neregistrovaný)
Vyvratitelné nesmysly - ano, máte pravdu. Jenže nemůžete lidem upřít jejich podvědomé obavy z podobných technologií. Já osobně si myslím, že jsou oprávněné.
Ad děrné štíty - to je obecný argument, když už není co říct. Já si třeba myslím, že vynaložené úsilí se mělo dát jinam - na kvalitu jádra samotného prohlížeče. Prostě nervat do něj za každou cenu kdejakou technologii/fičuru. Např. stále nedokážu pochopit, proč spotřebovává můj spuštěný FF v poslední verzi ve správci úloh 5,3 GB RAM. Nehraju hry, semtam konzumuju a především vyvíjím obsah (cca instalovaných 5 doplňků). To je opravdu stojí takovou režii? Musíme mit v operačním systému daší pseudo-operační systém (prohlížeč)? Z části chápu argumenty proč ano, ale také vidím ty nevýhody, rizika. Proto jsem zpátečník?
-
> Jestli ale někdo chce dělat obrovské (skoro nativní) aplikace v browseru (aby využil rychlost bytekódu), tak to nepochopil princip vývoje aplikací v prohlížeči (otevřte si taskmanager/ps a podívejte se na režii prohlížeče).
To jsi evidentne nepochopil smer vyvoje aplikaci poslednich 5 let - protoze ano, presne takove aplikace se delaji, proto jsou tak extremne popularni ruzne SPA frameworky (Angular, React), protoze se v nich dela to, co drive byla desktopova aplikace s podobnym komfortem (lokalni data, okamzita reakce).
A i tam se toto muze vyuzit - vsak konec koncu napr. webpack uz ma vyvoj naplanovany - https://github.com/webpack/webpack/milestone/16 -
Diskobolos (neregistrovaný)
Srovnávat implementace Angular, React s aplikacemi typu unreal je blbost. To je asi takový rozdíl jako mezi vzduchovkou a dělem ráže 205mm. Mě nevadí implementace JS FW, které jsou postavené na interakci s DOMem a zajišťují onen dojem nativní aplikace - to je OK.
Mě vadí, že z prohlížeče se dělá neco co není - operační systém. Objevování novinek v IT se děje periodicky každých 15/20 roků. Za 10 roků se zjistí, že je to chybný krok. Z prohlížeče buď vznikne samostatný operační systém (google), nebo se začnou prohlížeče vracet k původní myšlence (jednoduchost).
Složitost systému dosáhne své meze a je motivací ke změně. Takto to funguje ve všem. Mě jenom udivuje, že současní vývojáři prohlížečů si toho jaksi nejsou vědomi a s klapkami na očích tlačí káru ke srázu rychleji, než by museli. -
> Srovnávat implementace Angular, React s aplikacemi typu unreal je blbost. To je asi takový rozdíl jako mezi vzduchovkou a dělem ráže 205mm. Mě nevadí implementace JS FW, které jsou postavené na interakci s DOMem a zajišťují onen dojem nativní aplikace - to je OK.
Skoda, ze to nikdo nerekl autorum Unreal Enginu nez ho na WebGL preportovali, ze to vlastne nefunguje a nema to zadny smysl :-)
Ze se zjisti, ze to je chybny krok - proc? Prohlizece se dale zrychli (jejich runtime enginy), CPU/GPU vykon dale poroste, stejne jako rychlost internetoveho pripojeni. Stejne jako se nikdo nevraci k desktopovym aplikacim od webovych (resp. rozhodne ne majorita uzivatelu), tak to nebude zde jine.
A prohlizec je z tohoto pohledu idealni aplikacni platforma - ma ji, potrebuji ji uplne kazdy. A diky temto technologiim zaroven vendor ziska pristup k mnohem vetsimu marketu, nebude muset resit napr. portaci na Mac OS, eventualne na Linux (i kydz co si budeme rikat, to moc vendoru nedela), je to win win situace.
