Assembly-szerű nyelv válthatja le a JavaScriptet a böngészőkben

Assembly-szerű nyelv válthatja le a JavaScriptet a böngészőkben
2015-06-18T10:09:49+02:00
2016-11-19T10:49:33+01:00
2022-10-20T03:25:37+02:00
  • A szerver oldali kliensre szánt kód pl. CIL (C#) vagy ByteCode (Java) a html-el együtt WASM-re fordul és megy a kliensre.

    Ez eddig is lehetséges volt - ti. hogy a szerveroldali keretrendszer egy másik nyelvben írt kódot keresztfordítson a kliensoldali környezet bájtkódjára (ami eddig a JavaScript volt). Praktikus okok miatt viszont ez a megoldás nem volt túl elterjedt. A WASM ezen semmit nem változtat. Azon se, hogy kliensoldali kódot jellemzően továbbra sem fogsz más nyelveken írni.

    Pont az a baj, hogy a böngésző miatt eleinte csak JS lehetett a kliens oldali kód, így a szerver oldalnak kellett alkalmazkodnia a kliens lehetőségeihez.

    Nem a JS miatt kellett alkalmazkodnia. És azon, hogy alkalmazkodnia kell, a WASM megint semmit nem változtat.

    A WASM lehetővé teszi majd, hogy csak egy nyelvvel, a szerver oldalival dolgozz és egy egységben tartsd a kliens és a szerver oldali kódodat (ami a kettő közötti kommunikációhoz kell).

    Ez eddig is lehetséges volt. A WASM ezen semmit nem változtat.

    Minden ilyen "szigorú" megoldás korlátja a JS volt, de pl. a WASM már lehetővé teszi ezeket a (szerintem fejlettebb és precizebb) megoldások használatát, ami csak akkor kényelmes ha egy egységben tartható a szerver+kliens kód.

    Dehogy volt korlátja a JS. Hiszen az egy dinamikus és laza nyelv, ami a nála szigorúbb, illetve statikus ábrázolást nyilván lehetővé teszi. Probléma pont ennek fordítottjából lett volna: ti. ha a JS statikus és előfordított lett volna, hiszen akkor dinamikus nyelvek ábrázolására nem, illetve csak rendkívül sok plusz kód révén lett volna képes. A lényeg mindenesetre, hogy a WASM ezen sem változtat.


    Te nyilvánvalóan nem érted, hogy a WASM az mindössze egy bájtkód, ami a JS-t, mint bájtkódot fogja váltani. Nem több és nem kevesebb. Minden előnye a JS-tal szemben abból ered, hogy utóbbihoz képest mennyivel effektívebb bájtkód. Viszont a lehetőségei nem tágabbak. Csak hatékonyabban képes ábrázolni kódokat, illetve egyszerűsíti a tárgykód generálását.
    Mutasd a teljes hozzászólást!
  • Pont a szerveroldali és a kliensoldali nyelvek sokaságáról beszélek.

    Ha a szerveren PHP vagy Java vagy C# nyelven írod a kódodat és abban van egy adatstrukturád, aminek az adatait a kliensen is használnod kell, akkor a szerver kódban(!) írod meg a kliens oldali html-be ágyazott kódot is (és így egy egységben tarthatod, azonos forrásból generálódik pl. az adatstruktúrád). A szerver oldali kliensre szánt kód pl. CIL (C#) vagy ByteCode (Java) a html-el együtt WASM-re fordul és megy a kliensre. 

    Pont az a baj, hogy a böngésző miatt eleinte csak JS lehetett a kliens oldali kód, így a szerver oldalnak kellett alkalmazkodnia a kliens lehetőségeihez.

    A WASM lehetővé teszi majd, hogy csak egy nyelvvel, a szerver oldalival dolgozz és egy egységben tartsd a kliens és a szerver oldali kódodat (ami a kettő közötti kommunikációhoz kell).

    Én használtam RPC-t (STUB kódgenerátorokkal C++-hoz). Az egy jól kiforrott megoldás a kliens/szerver közötti adatkommunikációra. A "laza" Json és a szigorú STUB pont úgy viszonyul egymáshoz, mint a JS "típusossága" és a C# típusossága.
    Van aki a laza, majd lesz valahogy megoldásokat preferálja, van aki a szigorúan megtervezett és betartatott szerkezetekét.

    Kinéztem a Google féle Protocol_Buffers-t is egy későbbi munkámhoz, ez meg azt mutatja, hogy még többféle környezet között is megoldható struktura verziózott, szigorúan típusos megoldás.
    Minden ilyen "szigorú" megoldás korlátja a JS volt, de pl. a WASM már lehetővé teszi ezeket a (szerintem fejlettebb és precizebb) megoldások használatát, ami csak akkor kényelmes ha egy egységben tartható a szerver+kliens kód.
    Mutasd a teljes hozzászólást!
  • ...remélem, minden böngészőre külön verziója lesz...
    Mutasd a teljes hozzászólást!
  • De ne felejtsuk el, hogy a scriptek letjogosultsaga ott van, ahol a nagy program futasanak megszakitasa nelkul mukodesbeli valtozast akarunk elerni, de olyat, amit még a megrendelo se tudott meghatarozni.
    Tehat ez a, "ha megy a dzsakuzzi, akkor ne menjen a kerti locsoló, de kapcsoljon be a kulso mozgaserzekelo" téma :D Na erre nincs jobb megoldas, mint a helyben ertelmezett script.

    Engem az akaszt ki, amikor egy blikk.hu a 4 core 1ghz csingcsangcsung telefonon 1 percen keresztul tolt be o.O A reklamok persze azonnal lent vannak, de a maradek 2KB text meg 8Mb kép az még várat magára egy percet, szal hihetetlen!

    En a vilag eletemben processzorokat programoztam, ott legalabb ha lassu vagy, akkor csak magadat szidhatod. Viszont ebben a webes vilagban tehetetlen vagy es nem csak magadat hanem még vagy harom layert szidhatsz, amihez viszont nem nyulhatsz hozza, hanem csak varhatod, hogy Sting ir rola valami jot, hogy ketszer gyorsabb lett ez, meg az :D
    Na ez sztem tré :D De mindent az ugyfelert!!!

    Amugy meg peace!
    Mutasd a teljes hozzászólást!
  • Én már csak olyan rendszereket szeretek tervezni, hogy a kliens és a szerver oldalunkon ugyanaz az osztály található, ezek között (ha nem sérül az adatátvitel, de ez ugye már egy szimpla CRC-vel ellenőrizhető) garantált a típusbiztos és tartalomhelyes adattovábbítás.

    És ezt hogy? Már csak a szerveroldali nyelvek sokasága miatt sem értem... Vagy te most nem is a böngészőről beszélsz, mint kliensről, hanem "kicsit" eltértél a témától?
    Mutasd a teljes hozzászólást!
  • Nem csak hatékonysági, de szemléletbeni kérdés is a bináris serializáció. 

    A text közbenső állapot arról szól, hogy gyengén csatolt a két oldal (kliens/szerver).
    "Valami" jön az egyik oldalról és "valahogy" értelmezi azt a másik és "valamennyit" felhasznál az adatokból.
    Ez nekem olyan nagyon laza, túl laza.
    Én már csak olyan rendszereket szeretek tervezni, hogy a kliens és a szerver oldalunkon ugyanaz az osztály található, ezek között (ha nem sérül az adatátvitel, de ez ugye már egy szimpla CRC-vel ellenőrizhető) garantált a típusbiztos és tartalomhelyes adattovábbítás.
    Nem csak hatékonysági kérdés, de rendszerbiztonsági is... szerintem.
    Mutasd a teljes hozzászólást!
  • Ha ez ilyen jo lesz, mint ahogy leirtad, akkor en mindenkeppen drukkolok neki!

    Ez a mondat viszont aggaszt/megmosolyogtat:
    "Amúgy alap weboldalak programozására marad a JS, a WebAssembly erre a célra ágyúval a verébre eset."

    Pont az imént írtad, hogy mennyivel egyszerubb egy ilyen veremgépre irt kodot atforditani a nativ processzorra, nem kell akkora infrastruktura hozzá, mint a JS forditashoz. Ez alapjan pont a JS-nek kell az ágyú, nem ennek a már éppenhogy futtatható valaminek! :D
    Mutasd a teljes hozzászólást!
  • Lehet, hogy negativan fog hangzani, de sztem ma mar akkora lett a bloatware mindenutt, hogy egy ascii-binary atmenet mar fel sem fog tunni. Persze en orulnek a legjobban, ha ez nem igy lenne, mert szeretem, ha fluid a browser :D
    (De a multheti Chrome belassulas sem ezt tamasztja alá. Most mar javitottak, de pfffffff mennyi ilyen lehet még benne, ami csak egyenkent par szazalekot lassit, de allandoan jelen van. Ez most egy parszaz szazalekos lassito bug volt, amit nem lehetett nem eszrevenni.)
    Mutasd a teljes hozzászólást!
  • Helosztok. Igazából a WebAssembly iszonyatosan jó dolog lesz és szerencsére ebben a nagy böngésző gyártok egyet is értenek (végre). MS, Google, Mozilla mind implementálja és már aktívan fejleszti a maga módján. FF nightly változatában már benne is van és alapértelmezésben aktív,lehet vele kísérletezni. Az igazi nagy előnye a natív sebességggel történő végrehajtás, illetve a WebAssemblyhez tartozó memóriamodell ami a programok jobb sandboxozásához vezet. GC csupán tervezett feature jelen pillanatban. Mindezek ellenére a legnagyobb előnye a komplex alkalmazások létrehozása ami akár bytekódra is fordítható és fordítási időben történő kód optimizáció is végezhető, ami jóval lassabb és komplexebb bárminél ami asm.js -nél JIT elképzelhető, emellett kompaktabb méretek végeredménnyel jár. Így akár komplex játék, távoli asztal, CAD/CAM program is kivitelezhető natív sebesség mellett. Bináris kódból könnyebb AOT / JIT módban az aktuális target platformra generálni egy optimizált gépi kódot. Ezenfelül a bytekód segítségével a stack machine működési elve miatt az értelmezés pikk pakk megy, össze nem hasonlítható egy gigászi szöveges JS projekttel és annak fordításával a kliensen és persze az adatforgalom tekintetében. Nincs szükség költséges fordítási folyamatra a kliensen. Illetve a bytekód úgy lett kialakítva hogy szinte bármilyen nyelvből lehessen rá fordítót írni ( jelen pillanatban C/C++ van)
    Amúgy alap weboldalak programozására marad a JS, a WebAssembly erre a célra ágyúval a verébre eset. Viszont a kettő együtt már nukleáris támadás. Más pályákon van értelme az egyiknek és a másiknak.

    ps.: Apple Safarijáról nem tudok semmit, bár mostanában nekem úgy tűnik az Apple azt játsza amit az MS a 2000-es évek elején az IE6 -tal
    Mutasd a teljes hozzászólást!
  • Szépen lépegetünk a kliens oldalon használható új programnyelvek felé, ami akkor kezd érdekessé válni majd, amikor a server oldali (pl. validációs) kód automatikusan megjelenik a kliens oldalon. Nem kell majd a jelenlegi "trükkökkel" JS beszúrásokkal valami 'hasonlót' csinálni, mint a szerveren.
    Ez kellően nagy WASM-et értő böngésző elterjedtség esetén fog robbanni.

    Csak primitív példa. Nem csak az XML kerül lejjebb az értékrendben, de a JSon-is. Végre megoldás lehet, hogy a kliens oldali Ajaxban a pl. C#/Java kód (WASM-re fordított tárgykódja) szépen binárisan sorosítja az adatokat és visszaküldi a szervernek vagy fordítva egy kérdésben bináris sorosított objektumpéldányt kap és kimarad ez a modernkori elmebaj az ascii-be írás hogy onnan visszakonvertáljunk bináris reprezentációba adatokat.

    Ha elkészül a háttértechnológia és a böngésző elterjedtség megfelelő lesz, valami nagy változás jöhet a html küldözgetés helyett is, valamiféle 'egylapos website' technologia, amit most is csinálnak JS-el, de sok a technikai akadály.
    Ha azonban pl. egy hagyományos GUI kliens oldali alkalmazást hasonló eszközök használatának lehetőségével böngészőbe lehet tenni... na az is jelentős változást hozhat.

    Szóval a potenciát én látom benne.
    Mutasd a teljes hozzászólást!
  • > Ami alapjaiban változtatja meg, és/vagy forradalmasítja majd a programozást! Vagy csak a webfejlesztést. Vagy érdeklődés hiányában pár év után abbamarad. (A helyes választ kérjük aláhúzni.)

    Nos, eddig melyik jött be?
    Mutasd a teljes hozzászólást!
  • "A "működik, de csak lassan" _mindig_ jobb, mint a "nem működik egyáltalán". "
    Nem jobb. Ha a program kiírja, hogy bocs, de ezen a böngészőn nem működöm

    Na, de hogy írja ki, ha már eleve nem is tud futni? Na, kezded már érteni?

    mert nem támogatja az asm.js-t

    Kár, hogy még mindig nem érted, hogy minden böngésző ami képes a JavaScript kódok futtatására, definíció szerint támogatja az asm.js kódok futtatását is. Így gyakorlatilag nincs olyan böngésző, amin nem futnak az asm.js kódok. Kivéve persze azokat, amik semmilyen kód futtatására sem képesek.

    Ha nekikezd 1 frame/sec sebességgel dolgozni, akkor a user azt a következtetést vonja le, hogy a program egy hulladék és igyekszik elfelejteni a cég nevét is.

    Egyrészt azt, hogy a program hány frame/sec sebességgel fut rengeteg faktor határozza meg. Pl. hogy mást ne mondjuk a lassú processzor vagy a hardveresen gyorsított grafika hiánya is befolyásolják ezt, és mind legalább annyit, de inkább többet nyomnak a latban, mint az, hogy a böngésző amúgy milyen sebességgel futtatja a JavaScript kódokat.

    A lényeg, hogy ha a júzer nincs tisztában ezzel a ténnyel (ti. hogy számos faktor együtt határozza meg a futási sebességet), és/vagy nem tudja mik ezek a faktorok, és/vagy nem tudja hogyan lehet javítani rajtuk, akkor így is, úgy is azt a következtetést fogja levonni, hogy a program egy hulladék. Vagy, hogy legalábbis az ő gépén/mobilján/stb. nem lehet normálisan használni. Teljesen függetlenül attól, hogy amúgy a program milyen nyelven íródott vagy technológiával készült (amit ugye ebben az esetben szintén nem fog tudni a felhasználó), vagy hogy a programot mennyire hatékony futtatja az aktuális böngészője, vagy futtathatná egy másik (amit megint csak nem fog tudni).

    Ugyanakkor a másik oldalon egy programot semmi nem akadályoz meg abban, hogy úgymond megállapítsa a futtatókörnyezet típusát, benchmarkolja a teljesítményét, illetve megmérje a saját futási sebességét, és ha ezek valamelyike nem tűnik megfelelőnek számára, akkor informálja a felhasználót erről a tényről. Illetve akár arról is, hogy ezt a problémát esetleg miként tudná orvosolni, egy másik, hatékonyabb és/vagy újabb futtatókörnyezet (pl. asm.js optimalizációkat is tartalmazó vagy akár a WebAssembly-t ismerő böngésző) letöltésével.

    Illetve, dehogy, mert egy dolog igenis megakadályozza mindebben a programot: az, ha eleve el sem tud indulni, még akár csak lassan sem. Amely esetben ugye azt sem tudja kiírni, hogy "bocs, de túl lassú a böngésződ" vagy hogy az nem támogatja azt a technológiát, amiben ő készült és/vagy amire neki szüksége van. Illetve, ilyenkor a felhasználó sem dönthet arról, hogy neki megfelel -e akár lassan is a program.

    Na, ezért is mindig jobb az, ha valami fut, de lassan, annál, mint ha egyáltalán nem fut. Mindig. Akkor is, ha te ezt, illetve a fent felsorolt evidenciákat sem látod és érted meg.

    Persze, ha csak egy egyszerű kliens oldali validációról van szó, ott nincs ilyen gond, de az asm.js célja pont a CPU intenzív feladatok végrehajtása.

    Egyrészt nem az a célja, hanem a kódgenerálás hatékonyságának növelése. Másrészt ha az lenne a célja amit írsz, a fentiek miatt akkor is igaz maradna, hogy a lassabb működés mindig jobb, mint a működésre képtelenség.
    Mutasd a teljes hozzászólást!
  • Nem jobb. Ha a program kiírja, hogy bocs, de ezen a böngészőn nem működöm mert nem támogatja az asm.js-t, akkor a user tudomásul veszi, hogy a böngészője régi, és frissít ha kell neki a program. Ha nekikezd 1 frame/sec sebességgel dolgozni, akkor a user azt a következtetést vonja le, hogy a program egy hulladék és igyekszik elfelejteni a cég nevét is.

    Persze, ha csak egy egyszerű kliens oldali validációról van szó, ott nincs ilyen gond, de az asm.js célja pont a CPU intenzív feladatok végrehajtása.
    Mutasd a teljes hozzászólást!
  • Mondom én hogy másként látjuk a dolgokat. 

    Szerintem te a felszínt kapirgálod én meg a filozófiát keresem a mélyben.... de ez csak az én szubjektív véleményem 
    Mutasd a teljes hozzászólást!
  • Egy programozási nyelv arról ismerszik meg leginkább (most a specifikáció és formális leíráson túl), hogy ad valamiféle programozási stílust, eszközkészletet, irányultságot.

    Nem erről ismerszik meg. Egyik programozási nyelv attól különbözik a másiktól, hogy mások az utasításai, szerkezetei, szintaxisa. (Illetve, ha nem mások, akkor azonos vele, vagy legalábbis részhalmazát képezi - mint ahogy az asm.js is a JavaScript-nek). Csakis előbbiek a programozási nyelv sajátosságai.

    A programozási stílus, irányultság, gondolkodásmód, ezzel szemben nem kötődik szigorúan egy-egy programozási nyelvhez, és nem azonosítja azt - pláne ha az itt is említett általános célú imperatív nyelvekről beszélünk. Ugyanaz a gondolkodásmód vagy stílus több különböző nyelvben is alkalmazható, és ugyanabban a programozási nyelvben is számtalan stílus vagy gondolkodásmód követhető a kódolás során.

    Ha a C++ fordítómtól ASM kimenetet kérek, akkor a kód formálisan assembly, de a lényegét tekintve nem az.

    Ennek a kijelentésnek semmi értelme. Valami vagy assembly nyelvű, vagy nem. És minden kód csak formálisan lehet assembly nyelvű, hiszen a programozási nyelv nem más, mint formai (reprezentációs) eszköz a kód ábrázolására. A kód minden jellemzője ami túlmutat reprezentációján, az nem nyelvi sajátosság, és ebből eredően értelmetlen nyelvi jellemzőként hivatkozni rá.

    As asszembly programozás ugyanis végig a processzor és az architektura kötöttségeinek és lehetőségeinek legjobb kihasználására koncentrál.

    Nem koncentrál az semmire. Az csak egy kódreprezentációs formátum, programozási nyelv. Koncentrálni legfeljebb a fejlesztő koncentrál - már ha teszi. Mert hogy ugye assembly-ben is lehet "a processzor és az architektúra kötöttségeit és lehetőségeit" ki nem használó kódot írni, és más nyelvben is lehet olyant programot, ami meg aktívan épít ezekre. Tehát utóbbiak nem nyelvfüggő, és pláne nem a nyelvvel azonosítható sajátosságai a kódnak.

    A C++-ból fordított ASM kód, na az nem felel meg ennek a kritériumnak, vagyis az nem azonos dolog.

    A C++-ból fordított assembly kód is assembly kód. Lásd fent.


    Amúgy meg ez a téma teljesen vakvágány, illetve offtopic, hiszen nyilvánvalóan semmi köze nincs a WebAssembly-hez vagy a webhez, még marginálisan sem.
    Mutasd a teljes hozzászólást!
  • Az asm.js nem más nyelv, hanem a JavaScript egy alkészlete.

    Formálisan igazad van, a lényeget(!) tekintve meg eltájoltad magad.

    Egy programozási nyelv arról ismerszik meg leginkább (most a specifikáció és formális leíráson túl), hogy ad valamiféle programozási stílust, eszközkészletet, irányultságot.
    A JavaScript egy nyelv és nem a formális része érdekel, hanem a hatékonyan megoldható feladatok köre, a hozzá használatos know-how-k és algoritmusok, környezet és eszközök.
    Ebben a kontextusban az asm.js teljesen más dolog.
    Más a célja, mások és másra használják... egy alapvetően más nyelv.
    Persze a szintaxisban és a használati körben, eszközökben azonos, csak éppen ég és föld.

    Hogy egy példával megvilágítsam.
    Ha a C++ fordítómtól ASM kimenetet kérek, akkor a kód formálisan assembly, de a lényegét tekintve nem az.
    As asszembly programozás ugyanis végig a processzor és az architektura kötöttségeinek és lehetőségeinek legjobb kihasználására koncentrál.
    A C++-ból fordított ASM kód, na az nem felel meg ennek a kritériumnak, vagyis az nem azonos dolog.
    Mutasd a teljes hozzászólást!
  • Na, most akkor olvasd el még egyszer, hogy mit írtam! Amikről te beszélsz, azok a legacy célú felhasználások, ahol azért van még ott a Flash a weben, mert korábban rá/benne írtak meg valamit, amit - legalábbis egyelőre - nem érdemes újraírni.

    Pl. az elmúlt egy-másfél évtizedben legyártott számos apró webes játék, az online bannerek, stb. De gyakorlatilag sehol nem használják új dolgok létrehozására a weben, hanem mindenhol, ahol csak lehet, próbálnak megválni tőle. Végül - pár éven belül - vélhetően ezek a felhasználási módjai is meg fognak szűnni.

    Ami persze nem csoda, hiszen egyre kevesebb böngészőben van ott a támogatása, és amiben még ott van, abban is egyre korlátosabb. Végül pedig az Adobe saját maga is HTML5-re tér át Flash-ről, ahol csak lehet.
    Mutasd a teljes hozzászólást!
  • Szerintem a statisztikáid tévesek. Pdp-10 és Commodore-ok azért maradtak néhol, mert hobby / nosztalgia céllel pár amatőr "hazavitt" egyet. A flash viszont azért maradt, mert totál türelmetlenség van mindenütt a webes világban, mindenki kész frameworköket használ, és mindegyikben ott van benne a flash valamilyen formában. Most nem kezdem boncolgatni konkrétan melyik oldal mire használja, de épp csak kószálj kicsit a weben és figyeld a process listádat: folyamat bejön a flash plugin új oldal töltésnél újra meg újra, hiába állítottad le. 100% közeli a népszerűsége a flash-nek még mindig. Az összes, ami megváltozott, hogy már annyira sem értenek hozzá, hogy tudatosodjon a használata, hogy az van az fw-k mélyén.
    Mutasd a teljes hozzászólást!
  • Azért kakukktojás, mert az egy beágyazott nyelvnek tekinthető, amire más nyelven kell fejleszteni.

    Az asm.js nem más nyelv, hanem a JavaScript egy alkészlete. És éppen csak annyira kell rá más nyelven fejleszteni, mint amennyire bármilyen más nyelvre is más nyelven kell fejleszteni. Nem szükséglet, csak lehetséges.

    Jól látszott, hogy itt a JavaScript csak egy nyűg, mert mint virtuális gép használták, nem mint script nyelv.

    Ami ugye megint nem igaz. Ti. sem az, hogy a JavaScript használata a múlt lenne, sem az, hogy jellemzően valamiféle virtuális gép implementálására használnák. Persze arra is lehet - mint ahogy minden Turing-teljes imperatív nyelvet lehet erre használni. De nem ez a jellemző.

    Ezt gondolták tovább és kap a web rendes virtuális gépet, rendes bájtkóddal.

    A WebAssembly-t a JavaScript továbbgondolásának nevezni kb. annyira értelmes, mint a Pascal-t a C# továbbgondolásának nevezni. Vagy a Haskell-t a PHP továbbgondolásának. Közük nincs egymáshoz. És a WebAssembly bájtkódja semmivel sem "rendesebb", mint akár a JavaScript, akár az asm.js, mint bájtkód. Az egyetlen különbség a közöttük, hogy míg a WebAssembly bináris, addig a JavaScript/asm.js szöveges formátumú. Illetve, hogy míg utóbbit minden böngésző futtatja, addig a WebAssembly-t jelenleg egyik sem.

    Úgy lett kiiktatva, hogy most lesz Bármilyen Nyelv (elsőre csak C/C++) -> WebAssembly fordítás és kimarad a JS.

    Ez nem kiiktatás, hanem egyszerűen targetváltás. Nem JavaScript-re/asm.js-re, hanem WebAssembly-re fordítják a kódokat. Ami mellesleg éppen úgy egy tranziens, köztes bájtkód lesz, mint bármilyen portábilis bájtkód. Tehát itt sincs semmi változás, kiiktatás. Minden marad ugyanaz. Csak most nem X, hanem Y bájtkódra fordítják majd a dolgokat, és majd abból fordítanak gépi kódba. Puff neki.

    Max. azt lehet most, hogy JS-re fordítasz, ilyen értelemben megkerülhetetlen és monopol helyzetben van. Azzal, hogy ezt a bináris bájtkódot meglépik, azzal teljesen kimaradhat a fejlesztői láncból a JS. És ha már kimaradhat, akkor jöhet helyett bármilyen másik nyelv, ami egyértelmű cél.

    Nem az a cél. Nincs is a deklarált célok között, és nem is lehetne, mert ez a cél már megvalósult, és mert egy új bájtkód ehhez semmivel sem visz közelebb. A WebAssembly-nél az architektúra ugyanaz marad, mint a JavaScript/asm.js esetén volt, csak a köztes (bájt)kódrendszer változik.

    Ezzel összefüggésben éppen annyira lehet majd bármilyen nyelven programozni rá, mint ahogy eddig is lehetett. Amit szintén megmutattam már, hogy ti. eddig, a JavaScripten, illetve asm.js-en, mint bájtkódon keresztül is számos nyelven lehet.

    Nyilván ezen nyelvek száma nem fog jelentősen változni attól, hogy most WebAssembly lesz. Sőt, pont azért, mert utóbbi új bájtkód, azon keresztül pont, hogy egyelőre kevesebb nyelven lehet majd böngészős környezetbe fejleszteni, mint eddig lehetett. Ezért sem lehet igaz az a célra vonatkozó állításod.

    De mi értelme ennek a JS-re fordítgatós dolognak?

    Ugyanaz, mint a WebAssembly-re fordítgatós dolognak. Az, hogy egy minden böngészőben futtatható, portábilis és sandboxolható reprezentációját kapjuk a programunknak.

    Miért pont JS-re fordítunk és nem egy sima bájtkódú VM-re?

    Mert a JS az a bájtkód, amit jelenleg minden böngésző tud értelmezni. Ami ugyanakkor nem feltétlenül rosszabb, mint akármilyen másik bájtkód. Illetve az egyetlen egyértelmű hátránya az, hogy szöveges, ami nem hatékony az átviteli és betöltési sebesség szempontjából. Ez pontot próbálja orvosolni a WebAssembly. Semmi mást. Minden más fejlesztés amit a WebAssembly hozhat, az JS/asm.js-ben is éppen úgy megvalósíható lenne.

    Rájöttek, hogy semmi értelme és meg is csinálták a bájtkódú VM-et.

    Nem arra jöttek rá, hogy semmi értelme, hanem arra, hogy már csak egyetlen módon lehet tökéletesíteni rajta: úgy, hogy szövegesről bináris bájtkódra váltanak. A WebAssembly jelenleg csak ezen a ponton rendelkezik bármi egyértelmű előnnyel a JavaScripthez/asm.js-hez képest. Ami mellesleg bizonyítja, hogy ezt az egy dolgot leszámítva utóbbi koncepció maga is tökéletes.

    Egyelőre ígéretesnek tűnik, ami nem szenved a korábbi próbálkozások hibáitól.

    Persze, hogy nem, hiszen nem is létezik. Így hibái sincsenek. Mármint azt az egy kibtul nagy hibát leszámítva, hogy nem létezik és nem használható.
    Mutasd a teljes hozzászólást!

  • Kakukkfióka? Hogyan? Miért? Mihez képest? Milyen értelemben?

    Upsz... kakukktojást akartam írni, ami kikelt és WebAssembly lett belőle. Azért kakukktojás, mert az egy beágyazott nyelvnek tekinthető, amire más nyelven kell fejleszteni.

    Ez a legjobb esetben egy tautológia ("azért volt csak JavaScript, mert csak JavaScript volt"), rosszabb esetben egy teljesen értelmetlen kijelentés. Ráadásul semmi köze ahhoz, amiről szó van.

    Jól látszott, hogy itt a JavaScript csak egy nyűg, mert mint virtuális gép használták, nem mint script nyelv. Ezt gondolták tovább és kap a web rendes virtuális gépet, rendes bájtkóddal.

    Hogy lett volna kiiktatva, amikor ő az egyetlen technológia, ami még jelenleg is megtalálható minden böngészőben, miközben minden más kihalt mellőle?

    Úgy lett kiiktatva, hogy most lesz Bármilyen Nyelv (elsőre csak C/C++) -> WebAssembly fordítás és kimarad a JS. Persze egy ideig még a kompatibilitás miatt lehet WebAssembly -> asm.js fordítást csinálni.

    És hogyan lett volna kiiktatva, amikor a WebAssembly nem a JavaScript helyére, hanem mellé kerülne be az új böngészőkbe is?

    A JS nyilván megmarad és mellette lesz, de már nem lesz rá feltétlen szükség. Eddig megkerülhetetlen volt, most majd nem lesz az.

    És hogyan lett volna kiiktatva, amikor a WebAssembly még egyetlen böngészőben sem működik?

    Most a múlt idő használatát kéred számon? Nyilván úgy értem a dolgot, hogy létrehoztak egy olyan webes futtatási rendszert, amiből kimaradt a JS. Egyelőre jó esélyei vannak, hogy megvalósuljon, hisz az asm.js és a PNaCl fejlesztői is benne vannak a projectben és támogatjaőket az MS és az Apple is.

    A cél nem ez. Egyrészt, mert a JavaScript nincs semmiféle monopol helyzetben. Másrészt, mert a valódi cél a szöveges ábrázolással összefüggő átviteli és feldolgozási többlet kiiktatása.

    Max. azt lehet most, hogy JS-re fordítasz, ilyen értelemben megkerülhetetlen és monopol helyzetben van. Azzal, hogy ezt a bináris bájtkódot meglépik, azzal teljesen kimaradhat a fejlesztői láncból a JS. És ha már kimaradhat, akkor jöhet helyett bármilyen másik nyelv, ami egyértelmű cél.


    Értelmetlen a kérdésed, illetve hamis az abban megfogalmazott állítás, hiszen vagy félszáz másik nyelv is használható a böngészőben futó programok írásához.

    De mi értelme ennek a JS-re fordítgatós dolognak? Másrészt a fordítás többnyire erősen kompromisszumos. Miért pont JS-re fordítunk és nem egy sima bájtkódú VM-re? Rájöttek, hogy semmi értelme és meg is csinálták a bájtkódú VM-et.

    Ráadásul egyelőre nem, hogy ott nem vagyunk, hogy mindegyik nagy böngésző támogatná, de konkrétan még egyetlen egy sem teszi. Sőt, még az a specifikáció sincs kidolgozva, amit támogatniuk kellene. Ilyen helyzetben meg, hogy finoman fogalmazzak: "bátor" dolog bármit is jósolni a jövővel kapcsolatban.

    Egyelőre ígéretesnek tűnik, ami nem szenved a korábbi próbálkozások hibáitól. Nyilván 1-2 év alatt kiderül, hogy mi lesz belőle.
    Mutasd a teljes hozzászólást!
  • Az asm.js ugyanakkor egy igazi kakukkfióka a JS nyelvben

    Kakukkfióka? Hogyan? Miért? Mihez képest? Milyen értelemben?

    Csak azért volt eredetileg JavasScript, mert nem volt más futtatási lehetőség.

    Ez a legjobb esetben egy tautológia ("azért volt csak JavaScript, mert csak JavaScript volt"), rosszabb esetben egy teljesen értelmetlen kijelentés. Ráadásul semmi köze ahhoz, amiről szó van.

    Tulajdonképpen a JavaScript vált a szűk keresztmetszetté a fejlődésben, ezért lett most az kiiktatva.

    Hogy lett volna kiiktatva, amikor ő az egyetlen technológia, ami még jelenleg is megtalálható minden böngészőben, miközben minden más kihalt mellőle? És hogyan lett volna kiiktatva, amikor maga a WebAssembly is a JavaScript-re építené a visszafelé kompatibilitását? És hogyan lett volna kiiktatva, amikor a WebAssembly nem a JavaScript helyére, hanem mellé kerülne be az új böngészőkbe is? És hogyan lett volna kiiktatva, amikor a WebAssembly még egyetlen böngészőben sem működik? 

     Egyértelmű cél, hogy a JavaScript monopol helyzetét felszámolják.

    A cél nem ez. Egyrészt, mert a JavaScript nincs semmiféle monopol helyzetben. Másrészt, mert a valódi cél a szöveges ábrázolással összefüggő átviteli és feldolgozási többlet kiiktatása.

    Mert mi értelme van annak, hogy csak a JavaScript nyelv használható a weben?

    Értelmetlen a kérdésed, illetve hamis az abban megfogalmazott állítás, hiszen vagy félszáz másik nyelv is használható a böngészőben futó programok írásához.

    Most jön DOM integráció is és nem az lesz, hogy az a téglalap ott az oldalon egy fekete doboz és benne fut a Flash vagy a Java.

    Milyen DOM integráció? És mi köze annak a Flash-hez és a Java-hoz? És mi nem lesz, miért?

    A korábbi megoldásoknak mind volt valami problémája.

    De szerencsére ez az új megoldás viszont nyilván tökéletes lesz. Vagy legalábbis egyeseknek annak tűnik. Mint a maga idejében minden korábbi, időközben elbukott alternatíva is.

    Legközelebb talán a PNaCl jutott a mostani wasm-hez, de azt a Google nem tudta elterjeszteni az IE és Mozilla böngészőkben, így jogosan megvolt a félelem egy lock-in szituációtól. Most viszont az lesz, hogy minden nagy böngésző támogatni fogja a WASM-et.

    Minden nagy böngésző támogatta a Flash-t is. A Java-t is. Ezek közül ráadásul a Java teljesen nyílt volt. Mégis mindegyik kihalt. Szóval az, hogy "minden nagy böngésző támogatja", nem garancia semmire.

    Ráadásul egyelőre nem, hogy ott nem vagyunk, hogy mindegyik nagy böngésző támogatná, de konkrétan még egyetlen egy sem teszi. Sőt, még az a specifikáció sincs kidolgozva, amit támogatniuk kellene. Ilyen helyzetben meg, hogy finoman fogalmazzak: "bátor" dolog bármit is jósolni a jövővel kapcsolatban.
    Mutasd a teljes hozzászólást!
  • Nem szakmai, technikai vagy hatékonysági oka van annak, hogy nincs (eddig?) egy bytekód alapú környezet sem beépítve az összes lényeges böngészőbe.

    Értelmetlen az állításod, hiszen volt több bájtkód alapú környezet is beépítve az összes lényeges böngészőbe. Említettem is őket. Ezek voltak a Flash és a Java is. Mindegyiknek 90% feletti részesedése volt - sőt, a Flash-nek konkrétan 99%-os is.

    Csak éppen a bájtkódból adódó vélt vagy valós előnyök nem bizonyultak versenyképesnek más sajátosságokkal szemben. Ezért buktak el előbbiek a JavaScripttel szemben, ami viszont jelenleg is megtalálható a böngészők 99%-ban.
    Mutasd a teljes hozzászólást!
  • Bocsi, hogy belekotnyeleskedek, de a flash mióta halt ki?

    Kb. 4-5 év óta. Nem abban az értelemben "halt ki", hogy sehol nem fut egyetlen példánya - hiszen ebben az értelemben egyetlen technológia sem hal ki. PDP-10-ből és C64-ből is nyilván működik még itt-ott. Viszont abban az értelemben kihalt, hogy az új böngészőkbe már nem rakják bele a támogatását, és amiben benne van, abból is leépítik, eltávolítják azt. Illetve, hogy ezzel összefüggésben ma már gyakorlatilag senki nem kezd új projektet benne. Ahol pedig még használatban van, ott azt keresik, hogy hogyan lehetne kiváltani, megszabadulni tőle.
    Mutasd a teljes hozzászólást!
  • mondhatnám a Java VM-et vagy a Flash-t is, amik mindegyike bájtkód alapú portábilis környezet volt. És éppen azért nem terjedtek el, illetve haltak ki

    Szerintem komoly szemléleti hiba ha nem érzed, mennyire sok az üzletpolitikai ok a döntések mögött.

    Nem szakmai, technikai vagy hatékonysági oka van annak, hogy nincs (eddig?) egy bytekód alapú környezet sem beépítve az összes lényeges böngészőbe.

    A JS-et [előretörését, egyedurakodóvá válását] (véleményeddel ellentétben!) sem technologiai, sem gazdaságossági vagy hatékonysági ill. akármilyen egyéb okok nem indokolják.
    Ez egy patthelyzet eredménye!

    A nagy piaci szereplők kompromisszum készsége gyengébb (volt?) mint az üzleti/technologiai kényszer a váltásra. Talán mára átfordult ez a mutató.

    A JS eredeti(!) funkciójára tökéletesen jó megoldás volt.
    De az igények, elvárások megváltoztak és mára csak azért létezik (ezekben az új funkciókban!) mert monopol helyzetben van.
    Ez nem szakmai döntés... hanem kényszer. Mint általában minden ahol monopoliumok diktálnak.
    Mutasd a teljes hozzászólást!
  • Még ne igyál a maci bőrére. Talán mindegyik böngésző támogatni fogja a wasm-et, de 5 böngésző 5 féle implementációval, én még nem lennék biztos benne, hogy az áldás lesz-e vagy átok. Bevezetni egy teljesen új technológiát üzleti széthúzással a háttérben, szerintem olyanból sikereset már régen nem látott a világ. Vagy várjunk csak. Látott már olyat valaha is?
    Mutasd a teljes hozzászólást!
  • De nem az alapján hívjuk valaminek a dolgokat, hogy mik voltak, hanem az alapján, hogy most mik. Az asm.js kód pedig pont emiatt JavaScript kód. Bármennyit pörögsz ezen, nem fog sikerülni "kikövetkeztetni", hogy nem az.

    Mondom, ez az egyik fele a dolognak. Az asm.js ugyanakkor egy igazi kakukkfióka a JS nyelvben, ami most kikelt és WebAssembly lett belőle. Csak azért volt eredetileg JavasScript, mert nem volt más futtatási lehetőség. Tulajdonképpen a JavaScript vált a szűk keresztmetszetté a fejlődésben, ezért lett most az kiiktatva.

    Ez nem logikus. Az asm.js-nek - mint már elmondtam - a lényege pont az, hogy a benne kódolt programok érvényes JavaScript kódot is képeznek, ebből eredően pedig olyan böngészőkben is működnek, amik semmit sem tudnak az asm.js-ről. És minden olyan megoldás, ami ezt a visszafelé kompatibilitás kiveszi az egyenletből, nem alternatívája az asm.js-nek - és JavaScriptnek sem.

    Attól hogy nem érted, még logikus. Azért mielőtt kvázi beszólnál a Google, Microsoft, Mozilla összefogásnak, érdemes lenne inkább újra átgondolnod a dolgokat. Egyértelmű cél, hogy a JavaScript monopol helyzetét felszámolják. Mert mi értelme van annak, hogy csak a JavaScript nyelv használható a weben? Miért pont az a nyelv?

    Ilyenből egyébként számtalan volt már. Lásd pl. NaCl, Dart VM, de mondhatnám a Java VM-et vagy a Flash-t is, amik mindegyike bájtkód alapú portábilis környezet volt. És éppen azért nem terjedtek el, illetve haltak ki, mert önmagában a bájtkód alapúság, illetve a futási sebesség teljesen lényegtelen volt, illetve az ma is. Csak akkor számít valamit, ha közben biztosított a visszafelé kompatibilitás is.

    Most jön DOM integráció is és nem az lesz, hogy az a téglalap ott az oldalon egy fekete doboz és benne fut a Flash vagy a Java. A korábbi megoldásoknak mind volt valami problémája. Legközelebb talán a PNaCl jutott a mostani wasm-hez, de azt a Google nem tudta elterjeszteni az IE és Mozilla böngészőkben, így jogosan megvolt a félelem egy lock-in szituációtól. Most viszont az lesz, hogy minden nagy böngésző támogatni fogja a WASM-et.
    Mutasd a teljes hozzászólást!
  • mondhatnám a Java VM-et vagy a Flash-t is, amik mindegyike bájtkód alapú portábilis környezet volt. És éppen azért nem terjedtek el, illetve haltak ki

    Bocsi, hogy belekotnyeleskedek, de a flash mióta halt ki? Még itt a prog.hu-n is behívom ezt az oldalt, máris 2 (!) FlashPlayerPlugin_17_0_0_188.exe *32 csücsül a process listámban.
    Mutasd a teljes hozzászólást!
  • Hát ugye ez az, ami nem igaz. A "működik, de csak lassan" _mindig_ jobb, mint a "nem működik egyáltalán". Ráadásul a böngészőben működő alkalmazások legtöbbje nem játék, illetve a futási sebességük nagyjából huszadrangú prioritás.
    Mutasd a teljes hozzászólást!
  • Ja. Csak nem sok értelme van, ha az asm.js helyett sima js-t futtató user játék helyett állóképeket lát. Akkor már jobb ha azt látja, hogy bocs de a te böngésződ nem támogatott.
    Mutasd a teljes hozzászólást!
  • WebAssembly Faq
    Szerintem ez jól összefoglalja az elképzelés lényegét:

    "As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++. However, by integrating with JS at the ES6 Module interface, web developers don't need to write C++ to take advantage of libraries that others have written; reusing a modular C++ library can be as simple as using a module from JS.
    Beyond the MVP, another high-level goal is to improve support for languages other than C/C++."
    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