Elkészült a runtime, amivel bárhol lehet majd futtatni WebAssembly kódokat

Elkészült a runtime, amivel bárhol lehet majd futtatni WebAssembly kódokat
2021-01-11T15:22:07+01:00
2021-01-12T15:44:47+01:00
2022-10-17T11:41:53+02:00
  • Ráadásul mivel runtime már ismert a típus, simán tud az alapján (akár típussal paraméterezett) optimalizált natív kódot fordítani a runtime egy csomó esetben, és mivel így már a típus(ok) invariáns, ezért nem is kell az említett ellenőrzéseket végezze lépten-nyomon. Viszont erre betrainelni a runtime-ot idő, ami egy rövidebb életciklusú alkalmazásnál (weboldal, AWS lambda stb) rosszabb user élményt nyújt, mintha előre típusra optimalizált kód fordulna. Ebben segít a WASM (többek között). Amellett, hogy megadható build targetnek egy csomó nyelven írt program számára.

    Illetve pont egy olyan cikkről van szó, ami WASM binárisok containerizációjáról szól, tehát semmi köze a JS-hez, meg a böngészőhöz. A WASM ellenfele szvsz nem a JS lesz hosszútávon, hanem a mainstream virtuális gépek (HotSpot/Graal/CLR). Hogy ezen a fronton tud-e majd gyökeret ereszteni az évtizedes előnyben lévő platformokkal szemben, az majd kiderül. Ha okosan csinálják, akkor a szűkösebb erőforrásokkal gazdálkodó eszközökön (desktop, mobile, cloud) valószínűleg biztosan.
    Mutasd a teljes hozzászólást!
  • Hali!

    Nagy tesvéred figyel téged / a hangja rádszól a falakból / mindenütt ott van, érzed / mégsem látható sehol.

    Nem értem ennek a BB-dalrészletnek a relevanciáját ebben az esetben, de ha várod, „hogy egy angyal érkezzen”, akkor tessék, itt vagyok.

    Egyébként amennyire én tudom, már az asm.js-nek is ez volt a trükkje.

    Lényegtelen, mert a téma nem erről szól – és ne is csinálj belőle egy újabb ilyen-típusos/-típustalan vs másmilyen-típusos/-típustalan nyelv topikot (mert közbe fogok avatkozni).

    Mutasd a teljes hozzászólást!
  • Nagy tesvéred figyel téged / a hangja rádszól a falakból / mindenütt ott van, érzed / mégsem látható sehol.

    Egyébként amennyire én tudom, már az asm.js-nek is ez volt a trükkje.
    Mutasd a teljes hozzászólást!
  • Nem egészen. A compile, parse értelemszerûen kimarad, az execute nem, csak a lentiek miatt gyorsul.
    Mutasd a teljes hozzászólást!
  • Hali!

    Ne kezdd!

    Mutasd a teljes hozzászólást!
  • @Lcoder sztem en is ezt irtam.

    @FBS nem tudom, hogy mennyit gyorsulna tole egy mezei weboldal. WASMot inkabb compute heavy dolgokra hasznalnak, nem mezei Angularos appok gyorsitasara.
    Mutasd a teljes hozzászólást!
  • Nem is leváltani kell, hanem helyére tenni.
    A script maradjon script (pár tucat forrás sor a weblap szövegében), a keretrendszer vagy alkalmazási könyvtár meg kerüljön a helyére, valami fejlett nyelven készítve, 'binárisba' fordítva.
    Mutasd a teljes hozzászólást!
  • Meg azért, ha van egy int típusú a, és b változód, akkor az a + b mûvelet során a rendszernek nem kell azon törpölnie, hogy a-ban illetve b-ben most int van, vagy float, vagy string, vagy kisnyúl.
    Mutasd a teljes hozzászólást!
  • Ebben a WebAssembly-ben készült már valami számottevő? Már úgy értem a titkos bitpénz-bányászaton túl.

    Peldaul a Figma is hasznalja.

    Ugyancsak sokan azt latolgatják, hogy vajon leváltja e a WASM a JavaScriptet.

    Akkor bizony rossz lora tesznek. A WASM modulokat ugyan ugy a bongeszo javascript motorja futtatja meg. Azert gyorsabb mint a sima JS, mert nem kell vele annyit bajlodnia (parse, compile, execute).
    Mutasd a teljes hozzászólást!
  • Nem, itt nem az a működési elv, hogy meglévő markup-ot módosítgatunk, hanem a markup-ot generáljuk egy razor engine-el. Ezért alapból nem kell JS a markup módosításához. De tény, hogy pl. egy két soros JS script tölti be a Blazor app-ot, gondolom, most csak így tudták megoldani...
    Mutasd a teljes hozzászólást!
  • Én most csinálok egy titkosított alapokon nyugvó valós idejű üzenetírási progit Blazorban, saját igényem miatt kéne + házi feladat volt részben. Nem gáz annyira a JS-re váltás rész, és ezt 5% alá lehet vinni, hiszen leredukáljuk a DOM elemek kiolvasására / frissítésére. Sokkal jobb, hogy utána C#-ban tudom a programot írni klasszikus módon, engem még a TS se nyert meg, valahogy gyorsabban tudok halad C# alól. Szóval én örülök. A JS részhez meg nem kell később nyúlni, ha tényleg csak kiolvasás/írás. Ami zavaróbb szerintem, hogy még kicsit nehézkes és kiforratlan a hibakeresés és kiírás. De hát valahol el kell kezdeni, majd javítanak rajta. :) Közben meg már ajánlott a Google nekem olyan cikket, aminek a címe, hogy miért rossz a WebAssembly, kb. arról szólt mert nem használják azok, akik JS-ben írtak eddig is. Hát nyilván, minek is váltatnának egy karikacsapásra? Nem kell azt leváltani, és mindent kidobni, majd idővel elterjed, és használja aki akarja.
    Mutasd a teljes hozzászólást!
  • Sőt szerintem ezt az egész DOM / HTML / CSS / SVG több ezer oldalas specifikációt kellene átgondolni, és gyártani valami egyszerűbbet amit a wasm meghívhat. De ezt már írtam más topikban.
    Mutasd a teljes hozzászólást!
  • Úgy érted, a blazor javascriptet is generál a WebAssembly mellé. Vagyis "változatlanul rá vagyunk utalva a Javascript-re, és annak változataira / böngészőtől függésére." ?

    Ennek ellenére legalább Blazor-ban láttam működő példát a WebAssembly használatára, köszi. Akkor lehet, hogy már csak két-három év.
    Mutasd a teljes hozzászólást!
  • Gondolom szerepet játszik az, hogy a WebAssembly-ből közvetlenül nem lehet elérni a DOM-ot.

    Közvetlenül nem, és mivel a WASM semleges architektúrával rendelkezik (nem JavaScript primitívekre épül, mint egyesek gondolják), legfeljebb akkor valósulhat ez meg, ha a böngésző oldaláról készítenek egy natív DOM-illesztést, amit a WASM kód meghívhat. Az pedig nem kis munka, de ki tudja, hátha lesz rá elég igény.
    Mutasd a teljes hozzászólást!
  • Blazorban nem kell elérnünk a DOM-ot, hisz mi generáljuk :)
    A viccet félretéve néha jól jönne azért, de nem jellemző...
    Mutasd a teljes hozzászólást!
  • Gondolom szerepet játszik az, hogy a WebAssembly-ből közvetlenül nem lehet elérni a DOM-ot. Vagyis változatlanul rá vagyunk utalva a Javascript-re, és annak változataira / böngészőtől függésére.

    Semmi baj, várunk még öt évet.
    Mutasd a teljes hozzászólást!
  • Ebben a WebAssembly-ben készült már valami számottevő? Már úgy értem a titkos bitpénz-bányászaton túl.

    Nem tudom, de mindenki, aki böngészőben futó alkalmazást akar fejleszteni és nem szereti a JS alapú nyelveket (vagy a létező kódja nem abban van megírva), évek óta azt várja, hogy mikor terjed el a webassembly, hogy végre az általuk szeretett/ismert/értelmesnek tartott nyelven tudjanak fejleszteni. Ugyancsak sokan azt latolgatják, hogy vajon leváltja e a WASM a JavaScriptet.
    Mutasd a teljes hozzászólást!
  • Ebben a WebAssembly-ben készült már valami számottevő? Már úgy értem a titkos bitpénz-bányászaton túl.
    Mutasd a teljes hozzászólást!
  • Nagyon jó kezdeményezés, kíváncsian várom a jövőbeli alakulását. Csak félek, hogy mai trendi js alapú platformok miatt nem fog tudni dinamikusan fejlődni. De ne legyen igazam.
    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