SG.hu·

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.

Kapcsolódó cikkek és linkek

Hozzászólások

Jelentkezz be a hozzászóláshoz.

© balee662008. 12. 12.. 00:17||#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!😄

roliika: javafx-et ismerjük, de szerintem kicsit el vannak késve vele.
© smokedoc2008. 12. 11.. 09:58||#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.

© roliika2008. 12. 11.. 09:07||#23
http://java.sun.com/javafx/ Kukk meg. 😊
© netrunner2008. 12. 11.. 08:20||#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).
© Anotino2008. 12. 11.. 01:04||#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.
© Juszufka2008. 12. 10.. 23:15||#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.
© balee662008. 12. 10.. 22:03||#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 -.-
© sly0072008. 12. 10.. 19:48||#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õ.
© gkalcso2008. 12. 10.. 19:00||#17
A c#-ból gépi kód lesz, tehát maximum ugyanolyan lehet a sebessége. 😛
© balee662008. 12. 10.. 18:34||#16
Nem értessz hozzá.