Már böngészőben is fut a teljes értékű PostgreSQL adatbáziskezelő - a WebAssembly-nek köszönhetően
2022-09-09T14:34:35+02:00
2022-09-11T16:01:49+02:00
2022-09-11T16:41:47+02:00
  • mi akadályozza meg a böngésző(motoro)k fejlesztőit, hogy egy gyors, direkt dom manipulációt lehetővé tevő interfészt tegyenek elérhetővé a webassemblyk felé?

    Biztos lesz ilyen nemsokára, amint eléggé elterjed a WASM. Nem mintha a több ezer oldalon specifikált HTML/CSS/DOM egyveleg lenne az egyetlen, vagy a legjobb megoldás grafikus felületek programozására.
    Mutasd a teljes hozzászólást!
  • Értem én 

    Nem. A válaszodból nyilvánvaló, hogy egy szót sem értettél meg a leírtakból. Még azt sem, hogy nem személyes preferenciát közöltem.

    Egy "teljesen általános célú futtatókörnyezet"-be nem lehet beinjektálni minden felhasználáshoz az adott feladathoz illeszkedő API-t?

    Na, és akkor most olvasd el újra és próbáld megérteni is azt a részt, ami arról szól, hogy lehet, csak adott esetben nincs értelme!
    Mutasd a teljes hozzászólást!
  • Egy "teljesen általános célú futtatókörnyezet"-be nem lehet beinjektálni minden felhasználáshoz az adott feladathoz illeszkedő API-t?
    Hmmm....
    Mutasd a teljes hozzászólást!
  • Hát ha a gyorsaság a cél, akkor nem nagyon kell belekeverni a JS-et, ha meg még a kényelem és biztonság is, akkor egy direkt API elérés helyett közvetítő kódot írni?

    Értem én hogy szereted, de ettől nem kellene lenyomni mindenki torkán :)
    Mutasd a teljes hozzászólást!
  • Akadálya nincs, csak értelme sem. Nem lenne semmivel sem gyorsabb, mint a JS-ből hívás. Akkor meg minek? 

    Nem a JS az ami és ha lassú, hanem maga a DOM manipulálása, ami lényegéből adódóan egy többszörösen is dinamikus szerkezet, és amit ezzel összefüggésben egy statikus kódból semmivel sem lehet hatékonyabban elérni, manipulálni, mint az (elvileg) dinamikus JS-ből (ami viszont a valóságban maga is fordulhat teljesen statikus kóddá a futtatómotorban).

    Ráadásul az egész teljesen ellentétes lenne az egész WA koncepciójával is, aminek egyik kifejezett célja, hogy ne a böngészőkhöz drótozott valami, hanem egy azoktól független, teljesen általános célú futtatókörnyezet legyen. Amiben így a DOM manipulációval összefüggő műveleteknek semmi helye.
    Mutasd a teljes hozzászólást!
  • Mint laikus kérdezem, kíváncsiságból: mi akadályozza meg a böngésző(motoro)k fejlesztőit, hogy egy gyors, direkt dom manipulációt lehetővé tevő interfészt tegyenek elérhetővé a webassemblyk felé? Tehát nem wa-js áthívásokra gondolok.
    Mutasd a teljes hozzászólást!
  • Innen már csak egy lépés, hogy futtassunk oprendszert a böngészőben hálózattal és fájlrendszerrel, persze a same origin policy és a CORS szabályait betartva, lol.

    Nem kell egy lépés, már van böngészőben futó oprendszer. Most még maximum arra jó, hogy komolyabb dolgok letöltése vagy telepítése nélkül kipróbáld milyen is egy Debian parancssor, de ki tudja mi sül még ki belőle. Manapság úgy is divat a mindenféle szintű virtualizáció, ebbe simán belefér hogy a böngésződ is virtuális gépként viselkedjen ha nincs kedved dedikált szoftvert használni a feladathoz.
    Mutasd a teljes hozzászólást!
  • Ahol már tartunk.

    Böngésző + Felhő = oprendszer

    És a WASM-el nagyot bővült az alkalmazásfejlesztő eszközpark lehetősége, a reálisan megalkotható kódok összetettsége.
    (JS-ben is lehet, de azért ott sok a nyögvenyelős helyzet, mert patkolják, patkolják, de nem arra találták ki, mint amivé vált.)
    Mutasd a teljes hozzászólást!
  • Mivel és miért? Mert a WebAssembly nem képes kiváltani a JavaScriptet (ti. vannak olyan dolgok, amiket WA-ból nem lehet megcsinálni, csak JS-ből), és mert a JavaScript sokak által szívesen használt nyelv, böngészőn belül és kívül is.

    Én is szívesen használom a JS-t, vagy inkább a TypeScriptet. A "leváltás" nem volt átgondolt fogalmazás, de azt el tudom képzelni, hogy idővel csökken a JS aránya, vagy akár háttérbe szorul a böngészős alkalmazásokban.

    Mivel? Nekem úgy tűnik, hogy mindenki az általa favorizált nyelvet szeretné használni a böngészőben, és biztos vagyok benne, hogy a komolyabb nyelvek meg is kapják a WASM backendet. Azt értem, hogy a WASM nem egy JS virtuális gép akar lenni, nagyon távol van ettől, de libekkel meg lehet csinálni az illesztést és akkor közvetlenül az adott nyelven lehet GUI-t programozni. Így JS-be csak akkor "ereszkednek" le, ha nagyon kell, de inkább előkeresik a megfelelő komponenst a könyvtárból. Voltaképp a webprogramozók is sokszor ezt csinálják (nem megyek bele, hogy ki az igazi webprogramozó, mert én biztos kiesnék). Ha valaki főleg komponenseket használ, és maga inkább alkalmazáslogikát ír, azt más nyelven is megteheti.
    A fejlesztőeszköznek pedig csak kitérő, ha JS tárgykódot kell generálni.

    Az is látszik, hogy nagy divatja van a JS-re fordító, azt kibővítő nyelveknek, és ez is csökkenti a szülőnyelv jelentőségét, bár nem erősíti a webassembly-t.

    Miért? Mert sokan ilyen vagy olyan okból nem szeretik a JS-t, vagy túl nagy befektetésnek tartják kilépni a számukra megszokott ökoszisztémából. Úgy tudom, ma is vannak olyan fejlesztőeszközök, amik kiszolgálják ezt a csoportot, itt van mindjárt az említett Blazor. Egyeseknek az is vonzó lehet, hogy így könnyebb zárt forrású szoftvert írni.

    Egy biztonságos eszközfüggetlen ad-hoc hálózatos futtatókörnyezet.

    Tárgyilagos választ adtál a filozófikusnak szánt kérdésemre ami persze korrekt, de mégis a filozófia irányába terelném a szót. Hadd hozzam fel párhuzamként az x86-os architektúrát és a mobiltelefonokat. Az a közös bennük, hogy mindegyikből egészen más lett, mint aminek indult. A böngésző szerintem legalább három határt átlépett. Először akkor, amikor beletettek egy scriptnyelvet, amivel lényegében alkalmazásplatformmá vált. Másodszor akkor, amikor elkezdték lokális alkalmazásokra is használni (lásd Electron). Számomra ez a cikk is egy határátlépésről szól. Arról, hogy egy böngésző rendszerszintű szoftvert futtat. Innen már csak egy lépés, hogy futtassunk oprendszert a böngészőben hálózattal és fájlrendszerrel, persze a same origin policy és a CORS szabályait betartva, lol. Az evolúció nagy fricskája lenne.
    Mutasd a teljes hozzászólást!
  • Ez az első hír, ami kezd meggyőzni róla, hogy a JavaScript valaha is leváltható lesz a böngészőben.

    Mivel és miért? Mert a WebAssembly nem képes kiváltani a JavaScriptet (ti. vannak olyan dolgok, amiket WA-ból nem lehet megcsinálni, csak JS-ből), és mert a JavaScript sokak által szívesen használt nyelv, böngészőn belül és kívül is.

    Bár ez az eredmény a böngészés fogalmi határait is erősen feszegeti. Akkor végül is mi az, hogy böngésző?

    Egy biztonságos eszközfüggetlen ad-hoc hálózatos futtatókörnyezet. A JavaScript, ActiveX, Java appletek, stb. kora óta az. Az elmúlt évtizedek során csak az változott, hogy milyen technológiákkal, nyelvekben készítjük el a benne futó kódot.
    Mutasd a teljes hozzászólást!
  • Nálam a Blazor WASM-nél jött elő.
    A sok bespájzolt C# kód mehet a böngészőben is.
    Mutasd a teljes hozzászólást!
  • Ez az első hír, ami kezd meggyőzni róla, hogy a JavaScript valaha is leváltható lesz a böngészőben. Bár ez az eredmény a böngészés fogalmi határait is erősen feszegeti. Akkor végül is mi az, hogy böngésző?
    Mutasd a teljes hozzászólást!
abcd