Hivatalos WebAssembly specifikációterveket adott ki a W3C

Hivatalos WebAssembly specifikációterveket adott ki a W3C
2018-02-20T14:53:58+01:00
2018-02-26T07:45:49+01:00
2022-10-19T04:25:37+02:00
  • Miért adna ki bárki olyan böngészőt (lightweight vagy sem), ami nem viszi a weboldalak 90+%-át?

    A dillo meg a netsurf már most se viszi a weboldalak "90%-át" (bár nem 90 az - sok oldal működik azért JS nélkül). Van olyan lightweight browser ahol az SSL se default-ből támogatott, szóval amit írsz etekintetben nem releváns.

    Ha megcsinálja valaki azt amit mondtam, akkor annyit fog elérni, hogy az oldalak nagyobb százaléka megy majd a tök lightweight dolgokkal. A komoly weblapoknak idővel megéri remélem webassembly-re váltani és akkor legalább a nagyobb weblapok (pl. google docs) mehetnének ilyen minicuccokkal is. Ennek innentől kezdve semmi technikai akadálya.

    A WA nem arra van, hogy leváltsa a JS-t, hanem hogy kiegészítse.

    A JS egy programozási nyelv. A WA az egy bytekód. A WA arra való, hogy azokat az eseteket helyettesítse, amikor a JS-t csak bytekódként használták már ma is. Mivel a WA nem annyira tekinthető programnyelvnek így teljesen értelmetlen kérdés, hogy "leváltja-e" a javascript-et. Annyit akar csak elérni, hogy a web és a javascript ne legyen ennyire összefonódva: eddig az emscripten asm.js kódot generált amikor c++ból fordítottál webre és a mindenféle nyelvek is javascript-eket hánytak ki magukból a kliensoldali futtatáshoz akkor is, ha az generált kód volt. Ennek lássuk be: semmi értelme nincsen - a javascript nyelvet úgy használjuk ilyenkor, mint egy bytekódot. Kb. eddig ez volt a "web VM-je".

    Na arra való a WA, hogy ezt a használati esetet leváltsa egy direkt erre tervezett dologgal és ez szerintem igen örömteli

    ui.: Tanulságos, hogy egyébként eltérő közegben élőknek kinek mi a lightweight...
    Mutasd a teljes hozzászólást!
  • Ha végre szabványos az WA, akkor lehet majd idővel olyan lightweight böngészőket kiadni, ahol nem kell parser függőség, csak a WA függőség - amit könnyebb is lehet talán megírni és karbantartani.

    Miért adna ki bárki olyan böngészőt (lightweight vagy sem), ami nem viszi a weboldalak 90+%-át? A WA nem arra van, hogy leváltsa a JS-t, hanem hogy kiegészítse. Még ha holnap be is kerülne minden bőngészőbe (IE-t is beleértve) a WA támogatás, akkor ott lenne a rakás oldal, amit át kéne rá írni. Ráadásul ezen oldalak legtöbbje nem is profitálna a WebAssembly-re portolásból, mert nekik simán működik a mostani kódjuk is. Ha viszont marad a JS a weben, akkor a böngészőkben is maradnia kell.

    Én látom rosszul? Látsz valami olyan motiváló erőt, aminek a hatására a Javascript záros határidőn (mondjuk 10 éven) belül kipusztulna a webről?
    Mutasd a teljes hozzászólást!
  • Azt amikor van egy fordítóprogramod amivel lefordítod a kódod és azért lesz belőle javascript, mert kliens-oldali weben akarsz futni.

    Igazából ilyenkor a javascript neked csak egy "bytekód"-ként használt valami - attól eltekintve, hogy valami asm.js kimented lesz. Ehhez valszeg se JS-ből, se sehogy nem nyúlsz hozzá és semmi haszna, hogy ez "javascript", mert igazából csak a bytekód egy olyan formája, ami egy teljesen felesleges parzolási lépést tesz szükségessé - mint függőség.

    Az igazi igényed az ilyenkor inkább az, hogy a dom engine-t vezérelgessed. A JS téged ebben a helyzetben hidegen hagy.

    Ha végre szabványos az WA, akkor lehet majd idővel olyan lightweight böngészőket kiadni, ahol nem kell parser függőség, csak a WA függőség - amit könnyebb is lehet talán megírni és karbantartani. Ez utóbbi csak nekem számít, mert nem fogja érinteni a normális embereket, csak akik - mint pl. én is 10+ éves gépen tolják :D
    Mutasd a teljes hozzászólást!
  • Az mit jelent, hogy 'Javascriptet bytekódnak használni'?
    Mutasd a teljes hozzászólást!
  • A frameworkök néha gigantikusan nagy JS-eket "generálnak". Ezt nem csak le kell tölteni, de parzolni is kell.

    Igazából csomó mindenhez már most is asm.js-t használnak. Tök logikus, hogy ez a parzolás igazából felesleges ilyen esetben és jobb ha ott a webassembly.

    Majd ha lesz időm lehet hogy írok is hozzá assemblert . Én tökre örülnék, ha ennek a korlátozottabb változatait támogatnák mondjuk a primitív low-end böngészők mint mondjuk a netsurf meg hasonlók....

    Egyébként szerintem az benne a legkirályabb, hogy végre nem kell a Javascript-et bytekódnak használni akkor, ha értelmes nyelven fejleszt az ember a webre.
    Mutasd a teljes hozzászólást!
  • Amúgy belekavarodtam én is: a zárójelekben bővelkedő izé maga a webassembly olvasható változata, ami oda-vissza egyenértékű (és fordítható) a bytecode-jellegű wasm-mal, de JS-ből jelenleg csak az utóbbit lehet betölteni.
    Mutasd a teljes hozzászólást!

  • Látszik, hogy nem foglalkozom napi szinten a témával. Köszi a helyreigazítást.
    Mutasd a teljes hozzászólást!
  • Ehhez jön még a visszafelé kompatibilitás (a WA mezei JS kódként is értelmezhető, ha a böngésző nem ismeri fel), és a SlyWest által említett előre fordíthatóság.

    Az az asm.js. A wasm egy virtuális processzor nyelve, bytecode-szerűség, amit egy Lisp-szerű modulkezelővel importálsz, és utána hívogatod JS-ből. Rövid csámcsognivaló itt: Using the WebAssembly JavaScript API  . Ha más is mobilról nézné: mdn/webassembly-examples  az olvasható wasm linkje.
    Mutasd a teljes hozzászólást!
  • példa WebAssembly játékra

    Amikor az Unreal engine-t is láthattuk JS-ben, ez a mütymürütty most mit is demózik itt, mitől olyan nagy technológia?
    Mutasd a teljes hozzászólást!
  • Nem a legjobbtól kérdezed, mert nem mélyedtem bele a témába, de én már abból látok előnyöket, hogy nem pluginról van szó:

    - Stabilitás: a böngésző-fejlesztőknek gyakori panasza volt régebben, hogy a Flash miatt omlik össze a böngészőjük, de a felhasználó a böngészőt fogja hibáztatni. WA esetében a böngészőbe van gyógyítva a kód, nem külsős binárisba, úgyhogy nem veszélyezteti a stabilitást, vagy ha mégis, a fejlesztők nem tudnak harmadik félre mutogatni.
    - Integráció: lehet, hogy a Flash tudott JS kódot hívni és viszont, de amennyire én emlékszem, a Flash és a Java applet is elsősorban egy téglalap alakú kis saját területen dolgozott a böngészőn belül. Kényelmesebb volt elkülöníteni az appletet a környezetétől, mint integrálni vele.
    - Biztonság: a külsős pluginok általában valami saját sandbox szabályrendszerrel érkeztek, ami nem feltétlen egyezett a böngészőével. Flash plugin például akkor is tudott cross-origin kérést küldeni, amikor a "rendes" web még nem, és ezt saját konfigurációs fájllal szabályozta. De ott voltak a supercookie-k is, amik azon alapultak, hogy a Flash storage-et nem törli a böngészőben a history ürítése, és így újraéleszthetsz egy sütit.

    Ehhez jön még a visszafelé kompatibilitás (a WA mezei JS kódként is értelmezhető, ha a böngésző nem ismeri fel), és a SlyWest által említett előre fordíthatóság. Ha jól értem, onnantól, hogy egy WA kód lefordult (megfelelt a formai szabályoknak), már csak annyi kell a sandboxinghoz, hogy ne engedd hozzáférni a saját memóriáján kívüli területekhez. Ez azért egy nagyságrenddel egyszerűbb feladat, mint a normál JS dinamikus típuskezelése és szemétgyűjtése.
    Mutasd a teljes hozzászólást!
  • Forditasideju optimizaciot lehet vegezni, ami csomo ido lehet. Egy ilyen optimizat bytekod konnyebben es gyorsabban fordithato nativ kodra az adott platformon. A meretoptimizacio mellett ez is jo szempont.
    Mutasd a teljes hozzászólást!
  • Ez igy konkretan nem igaz. Per pill a webasm nem fer hozta a html elemekhez, igy a canvas elemhez sem. Ehhez ugynevezett glue kodot kell biztositani js-ben. Kesobbiekben ez valtozhat de addig meg sok viz lefolyik meg.
    Mutasd a teljes hozzászólást!
  • Ja, a natív kód.... persze :) De ezt javascript virtuális gép fogja futtatni nem? Akkor végülis megcsinálják mégegyszer a Java VM-et?
    Mutasd a teljes hozzászólást!
  • Akkor miben lesz ez más, mint a Flash vagy a JavaAppletek? Java beépülő alkalmazásokat nem tudom, hogy lehetett-e javascripttel vezérelni és fordítva, viszonta Flashnél lehetett kívülről bevinni adatott html űrlapból JavaScripttel.
    Mutasd a teljes hozzászólást!
  • Amennyire én emlékszem a specifikációra, ki- és belépési pontok vannak, ahol JS kód hívhat WebAssembly kódot és fordítva. A böngésző DOM-hoz és egyéb képességekhez továbbra is "mezei" JS kódon keresztül férsz hozzá, a WA kód pedig a számításokat végzi.
    Mutasd a teljes hozzászólást!
  • Annyi lesz a különbség, hogy lesz erre is 623.000 technológia, és szidni fogja egymást az a 1.246.000 ember, hogy melyik a jobb. :) 

    Engem az érdekel, hogy a web assembly-re fordítható nyelvekben el lehet-e érni a html elemeket és módosítani őket ugyan úgy, mint javascriptben, valamint az eventek is működnek-e ugyan úgy?
    Mutasd a teljes hozzászólást!
  • Meg az Assembly-ből nekem mindig az jön le, hogy a hardver közvetlen programozása :)
    Mutasd a teljes hozzászólást!
  • De úgy tudom, hogy a Javascript értelmezők ultra-mega-szupergyorsak, folyton csak erről hallani, olvasni stb. Meg hogy kisebb kód jönne le. Nem igazán vennénk észre ezt sebességben, mindjárt itt az 5G-s mobilnet, de még a 4G sebessége is leviszi az agymat... :D De a javascript fájokat is chacheli a böngésző, nem? Nekem tök sokszor onnan tölti be és tök idegesítő, mikor fejlesztés közben nézem, hogy miért nem hajtódik végre az adott művelet, amit beleírtam a .js-fájlba. Értem én, hogy előre lefordított bájtkód, de webes technológiában van ennek annyi értelme, hogy erre töblet energiát fektessünk? És legyen egy plusz dolog, amit meg kell tanulni a 623.000 webes technológia mellett és hogy legyen megint egy dolog, amit ha nem tudsz használni, akkor sz.r vagy? :) Tehát hogy webes technológiában ennek van-e létjogosultsága és nem csak egy olyan dolog, hogy miért ne csináljuk meg, ha egyszer lehetséges. Ha ezzel az előre lefordított kóddal megoldható az, hogy a felhasználó ne böngészgethesse a webalkalmazásom kliensoldali kódját és ne nézelődjön felhasznált librarykbe, akkor azt mondom, hogy végre már.
    Mutasd a teljes hozzászólást!
  • Elvadult elképzelésként akár olyasmi is elképzelhető, hogy egyes webalkalmazások nem szórakoznak tovább a html5-css-js combóval, hanem lesz egy 5 soros html, ami betölt egy teljes ablakos alkalmazást, saját UI-val (pl amilyen a Facebook/Gmail/akármilyen app a mobilokon). Teljes felépítés és funkció elrejtés.

    + a flashes játékok is megmenekülnek, és végre megszabadulunk az utolsó flash plugintöl is.

    Ötlet 2: az Adobe, ha van egy kis esze, nem hagyja veszni a sok befektetett munkát, hanem kiad egy Flash - WebAssembly compilert...

    példa WebAssembly játékra: Tanks! Demo - WebAssembly
    Mutasd a teljes hozzászólást!
  • Több dologra is:
    - a fejlesztő előre lefordítja egy modul kódját WebAssembly-re, ami így kisebb méretű, kisebb fájlt kell letöltenie
    - a böngésző tudja cache-elni, ha nincs változás, akkor nem kell újra letölteni
    - nem kell a böngészőnek kliens oldalon értelmezni a javascript kódot, gyorsabban indulhat a kód a böngészőben
    - egy modult több nyelven is le lehet készíteni: C++, Java jelenleg a leginkább támogatott, de alakul a javascript/Typscript és C# is. A fejlesztő a megfelelő tool-okkal egy byte kódhoz hasonló kódot készít. C# esetén pl. a .Net Framework isebb részei is belekerülnek a modulba, pl. Garbage Collector, ami interface tekintetében ugyan az, mint az eredeti, de ez egy teljesen ezen környezetre újraírt változat. A Java is hasonlóan működik. Ez nem azt jelenti, hogy egy .Net vagy java byte kód futna, hanem ugyan olyan "natív" kód keletkezik, mintha C++ -ban írták volna, csak kap "utiltity"-kat is ilyenkor.
    - a modult a böngészőben lehet hívni javascriptből
    - a modul eléri a böngészőn keresztül a Web API-t

    Én eddig jutottam az értelmezésben, s ha tévedek, akkor javítsatok ki.
    Nekem ebből az jön le, hogy leginkább "engine / üzleti logika" jellegű implementációra érdemes használni.
    Mutasd a teljes hozzászólást!
  • Tulajdonképpen mire is lenne jó a WebAssembly?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd