Gyurkity Péter

Gyorsítana a webalkalmazásokon a Google

A keresőcég legújabb projektje eredményeként a java, a flash, illetve számos egyéb platformnál jobb alternatívát kínálna a fejlesztőknek és az internetezőknek, mégpedig a kliens gépeken futtatott natív kóddal.

A Google a nem túl fantáziadús Native Client nevet választotta a projektnek, maga a kezdeményezés pedig egy olyan platformot takar, amely a webalkalmazások végrehajtását natív kóddal gyorsítaná fel. Arról korábban többször pletykáltak, hogy a cég saját operációs rendszerrel készül, a jelek szerint azonban kitartanak a webközpontú gondolkodás mellett, ez pedig a böngészőkben megjelenő kisebb-nagyobb alkalmazások gyorsítását igényli.

Napjainkban a webalkalmazásokat széles körben használják, elég ha csak a Google Docs csomagra, vagy a számos java-, flash-, illetve Silverlight alapokra építkező szoftverre gondolunk. A Native Client egy új alternatívát jelent ezen a területen, és a jelenlegi legnagyobb problémát veszi célba: a teljesítményt, vagyis a végrehajtás és a futtatás sebességét, amely nem éppen optimális. A webalkalmazások ugyanis általában a kliens számítógépek erejének kicsinyke töredékét veszik csak igénybe, a teljes számítási kapacitáshoz a platformok kialakítása révén egyszerűen nem férnek hozzá.

A CPU teljes számítási kapacitásának igénybe vételéhez ugyanis natív kódra lenne szükség - ezt, illetve valami ilyesmit tesz lehetővé a jelenleg kísérleti stádiumban lévő Native Client. A cél, hogy a fejlesztők és a felhasználók ugyanolyan sebességgel futtathassák ezen szoftvereket, mint a hagyományos asztali alkalmazásokat, megtartva a kívánt biztonsági szintet, ezzel is minimalizálva a támadási felületet az internet irányából. Példaként említenek egy képmegosztó oldalt, ahol a felhasználók az oldal elhagyása nélkül módosíthatnák képeiket - ehhez jelenleg Javascriptre, valamint szerveroldali feldolgozásra van szükség, a Native Client esetében viszont a kliens számítógép végezné a kép módosítását, a szerver felé pedig csak a végeredményt közvetítené, minimalizálva a hálózati forgalmat (mindezt automatizálva, a böngészőn keresztül futtatott alkalmazásokkal).

Maga a platform három komponensből áll: a runtime, a böngésző beépülője, valamint a GCC-alapú compiler eszközök. A Google egyelőre a fejlesztők figyelmét igyekszik felkelteni, ami nyilván nem lesz nehéz. A Native Client jelenleg  Firefox, Safari, Opera, és Google Chrome böngészőn fut, Windows, Mac és Linux rendszereken.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • balee66 #25
    Nekem sem tetszik, hogy a Google ebbe is belepofátlankodik. De hát úgy látszik, neki is minden kell, ő is ott akar lenni mindenhol, ...
    De már úgyis ott van mindenhol a hirdetései révén, szóval tök mindegy.

    Hát, elméletileg ha IE és FFox normálisan tudja kezelni a beépülőt (és miért ne tudná, ha Flasht is viszi mindkettő?), akkor csak ugyanazok a hibák jöhetnek elő mindenkettő (minden) browser alatt.
    Szóval nem úgy mint pl CSS, hogy egyik böngésző tudja 30%-ra, a másik 67%-ra, a harmadik 70%-ra... meg nem is kell foglalkozni azzal, hogy az egyik böngésző alatt meg van-e valósítva ez és ez a függvény (pl. XMLHttpRequest esete), hanem ha nem megy IE alatt, akkor FF alatt se fog, és viszont. Azért már ez is valami!:D

    roliika: javafx-et ismerjük, de szerintem kicsit el vannak késve vele.
  • smokedoc #24
    A googlénak mániája, hogy mindig előálljon egy újjal.
    Az emberek mindig az újdonságot keresik
    sokszor ugyanazt megveszik mert más a csomagolása.

    ez is megint egy okosság amit a szerencsétlen alap felhasználó akiket megcéloznak a kurva reklámjaikkal, ami a web2 egyik anyagi mozgatórugója, újra szenvedhet vele, béta szakaszba :nem megy, lefagyott anyád IE, firefox bug etc..)

    minek ez az eröltetett fejlődés??? csak lassan. mert még ezt sem éljük igazán.

  • roliika #23
    http://java.sun.com/javafx/ Kukk meg. :)
  • netrunner #22
    Hát igen, Java teljesen alkalmas lenne rá.
    Amúgy szerintem a Java appletek pont ilyesmire lettek kitalálva ha jól emlékszem. A képmódosítást megcsinálná az applet és az eredményt feltölti. Csak mostanában alig használnak appleteket. Meg az persze nem natív kód (csak közvetetten).
  • Anotino #21
    A c# kod sebessege <=, de inkabb < az assemblynel. Most az elerheto maximumrol van szo, nem egy "rosszul" megirt assembly kodrol.

    Egy jo compiler viszont olyan jol optimalizal, hogy sok esetben a "kezzel" takolt assemblyvel tenyleg csak alulmulni lehet az eredmenyt. Szerintem te erre gondoltal es ebbe nincs is ertelme belekotni. De ha sebessegbajnokot akarunk koronazni, akkor C kiutessel gyoz, es talan a c++ se van sokkal lemaradva mogotte. C#, Java es tarsai hozzajuk kepest handycappel indulnak, ertheto okokbol.
  • Juszufka #20
    Mi pedig csak azt magyarázzuk, hogy a háttérben a C# is assembly csak azt nem látod. Szövegértésből meg majd veszek könyveket, meg tanárhoz is el fogok járni.
  • balee66 #19
    Igen, ez programozó függő.
    Sehol sem mondtam, hogy a C# minden esetben gyorsabb, mint egy assembly kód.
    Szöveget értelmezni meg kéne tanulni -.-
  • sly007 #18
    Előfordulhat hogy C# kód jobban "rátapint a lényegre", ezért gyorsabb. De mondhatnánk azt is, hogy programozó függő.
  • gkalcso #17
    A c#-ból gépi kód lesz, tehát maximum ugyanolyan lehet a sebessége. :P
  • balee66 #16
    Nem értessz hozzá.