Amíg a JavaScript csak arra volt jó, hogy felszkriptelgessen vele az ember weboldalakat, addig nem volt annyira releváns a teljesítmény kérdése. Most viszont, hogy komplett app-ok és játékok íródnak JS-ben, már sokszor kezdik súrolni a technológia határait. Egyszerűen a JS mint nyelv nem képes kiszolgálni ezeket az igényeket. Több helyen felmerült annak is a lehetősége, hogy szükség lenne valamilyen egységes bájtkódra, olyasmire, amit pl. a Java is használ. Csak ugye ahány böngésző, annyiféle megoldás születne. Most, hogy a JavaScript kezd egységessé válni, megint lehetne külön külön böngészőre fordítani. Ez a cikk a jelenlegi megoldásokról, és a fenti problémakörről szól. Jelenleg a Mozillának van egy asm.js nevű megoldása, míg a Google-nek a Portable Native Client. De bizonyára az Apple és a M$ is elő fog rukkolni valamivel. Talán a megoldás pont az olyan cross-compilerekeben lesz, amiket annak idején a böngészők különbségeinek elfedésére találtak ki. Mint amilyen pl. a GWT.
http://www.infoq.com/news/2013/05/javascript-browser-bytecode
http://www.infoq.com/news/2013/05/javascript-browser-bytecode
A GWT-vel az a legnagyobb baj, hogy sokáig nagyon el akarta fedni a böngésző részleteit, Java-nak akarta mutatni a JavaScriptet, és nincs igazán jó transzformáció a két megközelítés között.
VálaszTörlésAz asm.js és a (P)NaCl szerintem csak nagyon specifikus esetekben hasznos, ezért valószínűtlen, hogy ezek el fognak terjedni.
A Dart-nál már az elején felmerült az egységes "Dart bytekód" - végülis sok JVM-es ember van mögötte -, de annak is vannak hátrányai (csak a parsing sebességet javítja, szemantikai ellenőrzésekre továbbra is szükség van). Egy betölthető snapshottal rendelkező VM még gyorsabb is tud lenni, mint a közös bájtkód alapúak, mert egy ellenőrzési körrel kevesebbet lehet beletenni, és a fejlesztési is gyorsabb, ha nem kell extra compile idő. Szóval én továbbra is a Dart-ra fogadok :)
Tudsz konkrét példát, hogy a Java-ból hol lehet rossz JS-t fordítani? Igazából én csak azt látom, hogy a Java kötöttebb valami, de ez nem feltétlen rossz.
VálaszTörlésAmúgy a Dart szerintem is jó irány, csak még nagyon gyerekcipőben jár. Plusz a Dart-JS fordító miatt egyben egy absztrakciós réteg is JS fölé. Tehát a fordító akár fordíthatna asm.js-es kódot is. De szerintem lenne fantázia egy Java-Dart cross-compilerben is, hogy lehessen Java kódokat újrahasznosítani, úgy, mint GWT esetén.
A fordítónál kérdés a forrás és a cél-nyelv absztrakciója, és azok kompatibilitása.
VálaszTörlésA GWT megpróbálta elrejteni a webes világot, rossz reflexeket szolgál ki (legalábbis ha leküzdötted az első akadályokat és tényleg webes alkalmazást akartál írni). Pl. egy csomó overheadet bele kell rakni a lefordított JS kódba, hogy pontosan replikálják a Java standard libek működési logikáját, és ha helyette a JavaScript "természetes" logikáját akarnád használni (mert teljesítményben sokkal gyorsabb), akkor csak kínszenvedés az egész.
Az asm.js megintcsak más absztrakcióval dolgozik, a webes világgal kb. nem törődik, csak egy limitált C++ -> JavaScript konverziót ad, ezért gyanús, hogyha web-intenzív feladatra akarod használni, akkor nem lesz kezes eszköz hozzá. Pl. szálkezelés, eseménykezelés, callbackek kérdésesek...
A Dart nem rejt el részleteket, kibővíti a webes világot, az API-t és az absztrakciót nagyon jól eltalálták. Mondjuk nem csoda, itt ez tervezési követelmény volt. A dart2js fordító nem fog asm.js-es kódot fordítani, erről a napokban volt valami blog is, amiben elemezték a részleteket és indokokat. A kód-újrahasznosítás elég limitált a GWT esetén is, ez szerintem csak elsőre hangzik jól, gyakorlati jelentősége kb. nulla. A dart2js fordító amúgy működik most már böngészőben, így akár élő környezetben újra lehet fordítani az alkalmazást, de ezt speciel nem tekinteném döntő érvnek, rengeteg módon el lehet érni ugyanezt mindenféle nyelvekkel.