Chrome: natív programkód és kiegészítők
2009. október 6. 00:35, kedd
A Google Chrome böngészője folyamatosan frissül és egészül ki újabb funkciókkal. Ezúttal a natív programkód futtatásának lehetősége, valamint a kiegészítők megjelenése ad okot a beszámolóra.

Hirdetés

Az első feladatot a Native Client, rövidebb nevén a NaCl végzi majd, amely tavaly december óta speciális kiegészítőként volt elérhető a Chrome böngészőben, mostantól pedig (legalábbis a "dev" jelzéssel ellátott tesztváltozatokban) a program szerves része. A 4.0.220.1 verziószámú Chrome ezen kívül a kiegészítők rendszerének további fejlesztését, véglegesítését tartalmazza, immár az opciók között elérhető gombokkal és funkciókkal.

A Native Client nevének megfelelően a natív programkód futtatását teszi lehetővé, amelynek hiánya eddig meglehetősen nagy hátrányt jelentett a webfejlesztők számára, különösen ami az egyre népszerűbb webalkalmazások szegmensét illeti. A lényeg itt a fejlesztők elmondása szerint azon van, hogy a Javascript és Flash platformon keresztül futtatott, a natív kódnál lényegesen lassabban végrehajtott programok helyett az AMD és az Intel chipjeit a lehető legteljesebb mértékben kihasználó alkalmazásoknak alakítsák ki a hátteret. Ezáltal lehetővé válna, hogy natív módban futtathassuk kedvenc webalkalmazásainkat a böngészőn keresztül (sok esetben nyilván a számítási felhőkre is támaszkodva, aszerint, hogy a program készítői ezt miként oldották meg).



A Google a maga részéről számos egyszerűbb példát is közölt, amivel illusztrálni szeretnék a Native Client integrálásában lévő lehetőségeket (ez utóbbi egyelőre Windows platformon elérhető a Chrome böngészőben), ám nem kell sokat gondolkoznunk ahhoz, hogy belássuk, milyen előnyöket nyújt majd ez a keresőcégnek bizonyos területeken. Példaként rögtön említhetjük a Google Docs platformot, amely ezáltal méretes löketet kapna a teljesítmény terén, így rögtön jobb pozícióból folytathatná a versenyt a hagyományos irodai programcsomagokkal, amelyek (különálló szoftverként) eddig is natív módban futottak.

A Native Client alapesetben letiltva érkezik (a most elérhető verzióban), engedélyezéséhez a böngésző indítását az alábbi paranccsal kell kiegészítenünk: "chrome.exe -internal-nacl". Mindenképpen érdekes lesz látni, ahogy a natív kódot a háromdimenziós gyorsításért felelős O3D platform egészíti ki nemsokára - egészen új területek nyílnak majd meg a programfejlesztők előtt.

Ami pedig a régóta várt kiegészítőket illeti, nos, ez még mindig nem mondható véglegesnek, de egyre inkább kirajzolódik a fejlesztők által elképzelt kép. Az egyes kiegészítőket immár külön ablakban vehetjük közelebbről szemügyre, frissíthetjük is azokat, ikonjaikat pedig a felső menübe húzhatjuk, így azok rögtön a címsor mellett kapnak helyet az egyébként igen spártai kezelőfelületen.
Kapcsolódó linkek
Laptopok

Már 49 900 Ft-tól!

E-book olvasók

Már 17 043 Ft-tól!

Tablet PC-k

Már 23 140 Ft-tól!

LCD monitorok

Már 19 800 Ft-tól!

részletek » részletek » részletek » részletek »
Megosztás
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
 

IT/Tech, Hardver
Tudomány, Mobil, Film, Játék
Hirdetés



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)
Sir Ny  
2009. okt. 09. 14:47 | válasz | #49
"adobe acrobat"

adobe acrobat, mint netes programnyelv?
2009. okt. 08. 17:46 | válasz | #48
Pontosan, és ez így van jól. Van verseny, lehet választani. Olyan, hogy tökéletes nincsen.
kvp  
2009. okt. 07. 21:54 | válasz | #47
"Az igazság az hogy az egész Webet újra kéne tervezni. Most gyakorlatilag több technológia együtt teremti meg a minimlis feltételeket. E helyett kéne egy db platform."

A szabvanyok tobb retegbol allnak. Van egy tcp/ip a kommunikaciohoz, egy http az adatok atvitelehez, egy xhtml a szoveges tartalomnak, egy css a formazashoz es egy javascript a kliens oldali logikahoz. Ez igy eleg szep kerek lenne, ha mindenki kovetne a szabvanyt. Az xml alapu html-nel jobb adattarolasi nyelv jelenleg nincs, kompatibilisebb mint az osszes tobbi, a css helyett hasznalhatnank xhtml-t is (hasznalhatunk is, a google pl. szokott), a javascript pedig pont arra jo amire kitalaltak. Ezzel szemben ott van a tobbi szabvany: flash, silverlight, adobe acrobat, microsoft word, postscript. Az alternativak kozzul melyik jobb? Szerintem egyik sem.
2009. okt. 07. 19:38 | válasz | #46
Használjatok Rubyt! :P
Mcsiv  
2009. okt. 07. 14:54 | válasz | #45
de ettől nem lett jobb a nyelv, csak még kaotikusabb;]
2009. okt. 07. 12:42 | válasz | #44
igen, hasonlo cipoben jarok en is, folyamatosan orlodni 3-4 nyelv kozott nem konnyu, egyik tipusos, a masik nem. Bar a php -nal most mar lehet osztalyneveket es tombot parmetertipuskent megadni :-).
2009. okt. 07. 09:45 | válasz | #43
Az igazság az hogy az egész Webet újra kéne tervezni. Most gyakorlatilag több technológia együtt teremti meg a minimlis feltételeket. E helyett kéne egy db platform.
2009. okt. 07. 09:42 | válasz | #42
Egyetértek. A javascriptben igan hamar meg lehet unni, hogy minden kib@szott műveletnél nézelődni kell, hogy most akkor milyen böngészőben vagy. Sebességben script kategóriában egy mandelbrot renderrel teszteltem a cuccokat és valóban sokat gyorsultak a motorok, de a flash action script mindent odaver. Tényleg ez nem natívhoz közeli cucc? A Flash player mit futtat tulajdonképpen? :)
Mcsiv  
2009. okt. 07. 09:22 | válasz | #41
igen, többek közt ez is. A PHP-t én is szeretem, egyszerű, kellően gyors és mindent meg lehet benne csinálni. Az egyetlen problémája hogy tákolt nyelv, értem itt ezalatt hogy pl az eljárások paraméterei között semmi összefüggés nincs, nézd meg hogy paraméterezel pl egy mb_convert_encoding-ot, egy explode-ot vagy éppen csak egy str_replace-t. Mindegyik más, ami megnehezíti a munkámat. C-ben egyszerre írok 400 sort és csak akkor kell tesztelnem, php-ban ez 40 sor és ebből 1-2 hiba már kapásból adódik a hülye paraméterezésekből. Jó tudom, meg lehet tanulni, de nekem, aki párhuzamosan használ 4-5 nyelvet, csak 1 szivat....
Sanyix   "Rest in Peace Sanyix" 
2009. okt. 07. 09:04 | galéria | válasz | #40
kifinomult? Egy olyan nyelv ami nem követeli meg egy változó típusának meghatározását, azt nem nevezném kifinomultnak.
Hát persze hogy nincs cross browser szívás, mivel a php a szerveren fut, nem a böngészőn :D
2009. okt. 06. 22:36 | válasz | #39
El tudnátok képzelni a Google honlapját úgy, hogy csak 1 szó van rajta? Ha nem akkor nézzétek meg itt:
Szélessáv
2009. okt. 06. 16:24 | válasz | #38
Nem tudom miért, de elsőre mindenki utókeveréknek néz :D

"A nyelvi buktatók szinte mindenütt ott vannak, a javascriptben tobb, de joval kevesebb mint a php-ban pl:)"

Na ez az, amivel nem értek egyet. A php szerintem egy egész kellemesen kifinomult nyelv, és nincs vele az a szutyok cross-browser szívás mint a js-el mindig. JS debugra mindig kétszer annyi időm megy el, mint a regexp/php/mysql kombókra.
Activex-et még nem használtam, de amennyit hallottam, nem egy leányálom csinálni bármit is alá, ha kapok egy normális felületet, ahol pythonban vagy c++-ban írhatok dolgokat, akkor annak örülni fogok.

És még mindig úgy gondolom, hogy a böngészőre írt 3d-s játékok jók lehetnek, sőt, egy 3d-s oldalt is el tudnék képzelni, ha nem csak egy böngészőn menne, hanem mindenen, de így eléggé neccesnek tűnik, biztos nem én leszek az, aki egy pár%-os, vagy akár 10 is később, piaci részesedésű chrome kedvéért nekiáll megcsinálni egyet. De fantázia van benne, és kezdésnek nem rossz!
Andr0   2008. 01. 23. óta regisztrált VIP fórumozó 
2009. okt. 06. 15:13 | válasz | #37
na msot akkor hogy kell ezt belőni? kevés vagyok én ehehz vki érthetőbben leírná vagy print scren mit hol kell átírni?:P
Mcsiv  
2009. okt. 06. 13:41 | válasz | #36
Ezzel egyetértek, teljesen normális programnyelv, sőt, kimondottan szeretem is (egy két appomhoz csináltam js interpretert is). A nyelvi buktatók szinte mindenütt ott vannak, a javascriptben tobb, de joval kevesebb mint a php-ban pl:)
Sebességben mostmár valóban sokat fejlődött, de még messze nem annyit, hogy azt mondja rá az ember, hogy igen, ebben mostmár bármit meglehet valósítani akár egy böngészőn belűl is. Legjobb példa arra, amikor valami térképszoftvert fejleszt az ember. A rengeteg geo számítás elvinné a js-t, ha nem terhelné át lehetőség szerint a szerverre.
Mcsiv  
2009. okt. 06. 13:36 | válasz | #35
Ne keverjük ide a .net-et, mert messze nem egy kategória a kettő. A Java VM-re nem sok megkerülési mód létezett, ami volt is, az esetek 99%-ban a külső lib-ekben volt kereshető. Az hogy a java lassú relatív, a server jvm elég sokmindent odaver sebességben, a client jvm valóban lassabb az egyéb eshetőségektől, de viszont elég jól el van szeparálva mindentől, és nem annyival lassabb, hogy számüzetésbe kelljen vonulnia. Nyugodtan kereshetsz java vs c,c+3 benchmarkokat.
A java-nak egyetlen nagy hibája, hogy sokkal könnyebb benne gány kódot létrehozni, ami jóval lassabb.
2009. okt. 06. 13:32 | válasz | #34
Mondjuk az, hogy a "Natív kód sebessége és a sandbox biztonsága" remek marketing szöveg, de semmi más szerintem.
2009. okt. 06. 13:30 | válasz | #33
A JavaScript rendes programozási nyelv. Vannak hibái, főleg nyelvi tervezési hibák, amik fennmaradtak a böngészők háborújából, illetve a W3C-nek köszönhetően is bekerült néhány nehézség, de ettől még rendes nyelv. Ma már abszolút lehet rá vastag klienst tervezni, van is rengeteg. A sebessége pedig nem a nyelv függvénye, hanem azé, hogy sokáig nem volt rá megfelelő futtatókörnyezet a böngészőkben. Mostanság már ez sem áll, elég csak a Chrome vagy a Safari JS engine-eket megnézni.
Mcsiv  
2009. okt. 06. 13:30 | válasz | #32
Így van, a java újra feltalálása technikai szempontból, más szempontból pedig egy hihetetlen gyors javascript. Javaból nemtudod piszkálni a dom tree-t, csak javascript-en keresztül. Ez egy ilyen érdekes hibrid lesz, amivel a konkrét tartalmat hihetetlen gyorsan tudod majd változtatni illetve számolásokat végezni. Pár évvel ezelőtt egy ilyen megmentette volna a fél életemet, akkoriban ugyanezt úgy oldottam meg, hogy egy javas könyvtár futtatta az erőforrás igényes eljárásokat, majd ezeket egy json alapú kapcsolaton megbeszélte az oldalban futó javascriptel. Gány-gány, de akkoriban csak ez volt;]
2009. okt. 06. 13:30 | válasz | #31
"Érdekes, a sun-nak mégis sikerült normálisan megoldani ezt a dolgot."

Hát akár hogy is nézzük, a JAVA még mindig lasabb, mint a natív, vagy a .NET. Valamint a JAVA VM-et is megszokták tudni kerülni. Akkor el lehet képzelni natív kód esetén milyen jók a kilátások.
Mcsiv  
2009. okt. 06. 13:26 | válasz | #30
"Ha a natív kód (Pl.: IE - ActiveX, FF - Plugin) vm-ben fut akkor, abból igazából az lesz, hogy mind az ActiveX sebességét elbukja, mind a "sandbox"-ot. Találnak majd jó kis biztonsági lyukakat és a sand box-nak köszönhetően mindent lasabban fog végrehajtani, kívéve mondjuk a számolást, de ha már tömböt indexel az is lassúlni fog."

Érdekes, a sun-nak mégis sikerült normálisan megoldani ezt a dolgot. Mellesleg biztonsági rések mindenben vannak, a linuxban, bsd-ben, windows-ban, solaris-ban mint oprendszerek. Böngészők részéről az ie, ff, safari, chrome mind-mind sebezhető most is. Nem is tudom hol hallottam már ezt, de sajnos igaz "A hibajavítás nem más, mint ismert hiba cserélése ismeretlenre."
Sanyix   "Rest in Peace Sanyix" 
2009. okt. 06. 13:07 | galéria | válasz | #29
guglinak lehet jelentkezni egy sallerért, mert ez a natív izé ez faszság.
2009. okt. 06. 12:55 | válasz | #28
OS nélkül a natív kód szépen mehetne is, de "picit" beleszólhat a futó oprendszer is :) Ha JIT compilerrel oldják meg, akkor a java lett újra "feltalálva". Egyébként a letöltöm és futtatom helyett lenne ez egy letöltöm és a böngésző indítja el című dolog? Én még benne vagyok a portolható azonnal indítható dologban persze az nem a böngésző környezetében fut...
2009. okt. 06. 11:43 | válasz | #27
"A nativ kod egy vm-ben fog futni, ahogy emlitettem, ez egy javascript/active-x kombo szeruseg, mivel orokolte a javascript "sandbox" szeru felepiteset - a kozvetlen hozzaferest a dom strukturahoz stb, az activex-es sebessegen."

Ha a natív kód (Pl.: IE - ActiveX, FF - Plugin) vm-ben fut akkor, abból igazából az lesz, hogy mind az ActiveX sebességét elbukja, mind a "sandbox"-ot. Találnak majd jó kis biztonsági lyukakat és a sand box-nak köszönhetően mindent lasabban fog végrehajtani, kívéve mondjuk a számolást, de ha már tömböt indexel az is lassúlni fog.
andersh   "Rest in Peace andersh" 
2009. okt. 06. 11:35 | válasz | #26
én is Utókeveréknek olvastam :D
Mcsiv  
2009. okt. 06. 11:27 | válasz | #25
nálad a pont, ez valóban a google os első fuvallatának tűnik, mivel netes cég révén valószínüleg ezen a platformon szeretne maradni, így kompromisszumokkal, de megpróbálja megvalósítani azt, amire neki szüksége van. Ezt majd idővel legyömöszöli mindenki torkán;]
Mcsiv  
2009. okt. 06. 11:25 | válasz | #24
A nativ az nem azt jelenti hogy a processzor szamara nativ kod. Vagyis a nativ relativ:D Ha a javahoz viszonyitjuk, ott is nativ kodot gyartasz. A nativ kod egy vm-ben fog futni, ahogy emlitettem, ez egy javascript/active-x kombo szeruseg, mivel orokolte a javascript "sandbox" szeru felepiteset - a kozvetlen hozzaferest a dom strukturahoz stb, az activex-es sebessegen.
syeren  
2009. okt. 06. 11:21 | válasz | #23
NaCl = konyhasó
Würth  
2009. okt. 06. 11:18 | válasz | #22
Ez a verzió már tud alapból reklámokat blokkolni ? ( lehet hülye kérdés volt )
2009. okt. 06. 10:58 | válasz | #21
Ráadásul eszesz-eket írtál utána. :DDD
2009. okt. 06. 10:57 | válasz | #20
ziipp  
2009. okt. 06. 10:21 | válasz | #19
Lehet, hogy ez már a most készülő Google operációs rendszer első fuvallata. Azt mondták, hogy az egészet a Chrome-ra építik majd. Hát itt van.

roliika: nem Utókeverék, hanem Ütökverek. :D

Blasta  
2009. okt. 06. 09:58 | galéria | válasz | #18
"Az első feladatot a Native Client, rövidebb nevén a NaCl végzi majd"

NÁCI??? Ez dejó :SSSS
kvp  
2009. okt. 06. 09:52 | válasz | #17
A nativ kod futtatasa azt jelenti, hogy a bongeszo automatikusan letolt es futtat egy nativ x86-os vagy mas platformra irt programot. A microsoft ezt hivja activex-nek es szinte az osszes bongeszos virus es fereg ezt hasznalja, ezert probalnak megszabadulni tole. Arrol nem beszelve, hogy egy bizonyos nativ kod csak egy adott geptipuson futthathato, tehat akinek mondjuk nem x86-os processzora van (es mondjuk nem a legujabb microsoft windows vagy egy google linux van rajta) az nem fogja tudni futtatni az adott kodot. Esetleg a fejleszoknek kulon meg kell irniuk minden weboldalba rakott tartalmat windows-ra, x86-os linux-ra, arm-os linux-ra, mips-es linux-ra, x86-os androidra, arm-os androidra, x86-os mac-re, stb... jo poen, de hatarozottan rossz otlet.

A bongeszos 3d hasznalhato otlet, de csak addig amig a document object model resze es javascript-bol erheto el es nem igenyli azt, hogy a bongeszonek meg kelljen engedni, hogy azt futtasson a gepen amit az eppen nezett weboldal keszitoje akar. Ez biztonsagi szempontbol egy minden vedelmetol megfosztott internet explorer 6-ossal egyezik meg, az emlitett bongeszonel megszokott kompatibilitasi gondokkal egyutt.
Crane  
2009. okt. 06. 09:50 | válasz | #16
Köszi Mcsiv. Most már így értem teljesen.
Moikboynak is igaza van. Ne mérte miért jó ez az egész.
Ha ennyire arra gyúrnak, hogy megint az legyen mint régen: Volt egy cégénél egy szerver (központi gép), ahol a programok voltak, és voltak a konzol gépek, ahol kezelték. Ennek mintájára most gondolom az a cél, hogy van egy szerver a neten, ami kínál egy szolgáltatást (pl. szövegszerkesztő, játék, stb), amit a netre csatlakozott kliens használhat.
Nyilván így az lesz a vége, hogy egy OS abból fog állni, hogy power off, joint internet. És minden onnan fog lejönni. Azaz az OS maga lesz a "böngésző". :)
Szép új világ lesz... Google lógóva. :D
Mcsiv  
2009. okt. 06. 09:47 | válasz | #15
te biztosan képes lennél rá...
Mellesleg o3d peldai kozott van egy-ket hasznos dolog is, amit lazan el tudnak kepzelni egy oldalon belul.
2009. okt. 06. 09:31 | válasz | #14
A baromarcúaknak talán nem böngészőre kellene fejleszteniük a 3d-s, hatmilliárd vertexes játékokat, mert az nem arra való.

Jah, és én natív kódban is írok olyan programot, ami kurva lassan fut.

Mcsiv  
2009. okt. 06. 09:28 | válasz | #13
Az o3d mar elerheto, anno nezegettem. Letoltod, telepited, utanna mar futnak a bongeszodben az o3d-s appok. (Fejlesztesi szempontbol egy canvas szeru dolog + egy js api -t kinal)
Mcsiv  
2009. okt. 06. 09:26 | válasz | #12
nah, utannanezve a dolognak, ez a native programkod nem mas mint egy activex-javascript kombo, hulyen kifejezve, de az. Egy gcc alapu fordito tarsul hozza, ennek a vegtermeket tudod az oldaladba agyazni, majd mindez egy jail szeru valamiben fut. (vagy megjobb pelda lenne a java, ami hasonlo elven mukodik, csak itt nem egy vm-ben fut, hanem nativan tamogatja az adott processzort.). Masszoval: spanyolviasz
2009. okt. 06. 09:24 | válasz | #11
"Vagy a Google most Mátrixot tervez" <- Kitelik tőlük, figyeld meg.
Crane  
2009. okt. 06. 09:11 | válasz | #10
Köszi Drawain a kiegészítést! ;)
Akkor ha jól értem, a natív kód futtatása lehetővé teszi, hogy valaki ír mondjuk C-ben egy kódot, és az a böngészőn keresztül a kliens gépén futhat?
Ha jól értem, akkor két kérdésem lenne:
- Miért kell ehhez a böngésző? :)
- Ha jól gondolom, így aztán végleg leomlik minden fal a kártékony kódok előtt. Vagy ezek a natív kódok valami "burokban" futnak?
Tovább az a gyanúm, hogy ebből akkora káosz lesz, hogy lehetetlenné fog válni a webfejlesztés.

Aztán: A 3D-s megjelenítés pontosan miért is jó mondjuk a weblapok esetében?
Ez olyan lesz mint a Flash. Először mindenki meg fog veszni érte, hogy fúúú de kaffaaa... Aztán miután kiélték, majd rájön mindenki, hogy tök felesleges dolog. (szerintem) ... van a WRML nyelv is úgy kb. 1995 óta. Akkor az miért nem hemzseg a neten?
Vagy a Google most Mátrixot tervez? :D
2009. okt. 06. 09:08 | válasz | #9
Nem is rendes programnyelv kezdjük ott.

Utokeverék helyesen írta, hogy nem fér hozzá minden erőforráshoz (szerencsére), amúgy a leglassabb script nyelvek közé való, ezért csak ámulok néha, hogy mégis sikerül néha egy egy teljes oldalt arra építeni, hogy majd a JS mozgatja a menüket, meg szűr, meg mindent csinál...jó..ok minden opredszeren fut..de iszonyat.
2009. okt. 06. 08:44 | válasz | #8
ok, kapitulálok, de köszi a felvilágosítást :D
2009. okt. 06. 08:41 | válasz | #7
Ez egyszerűen baromság amit írtál...

A natív kód itt azt jelenti, hogy más programozási nyelveken (pl. C vagy Python) írt programmodulokat itt előre befordítjuk, így csatoljuk az oldalhoz (a JavaScripttel ellentétben, ahol a böngésző interpretere a forráskódot valós időben értelmezi). Ezzel nyilván gyorsabb működés érhető el, de ettől még nem fog szebben vagy jobban megjelenni egy oldal a különböző böngészőkben, hanem épp ellenkezőleg, sok inkompatibilitási probléma forrása lehet.

A W3C-t se keverjük ide lehetőleg, nincsen szabványuk a böngészőben futtatható natív kódra.

Egyébként ezek csak kísérletezések a Google részéről (bár ha nagyon belehúznak persze lenyomják a webfejlesztők torkán őket), de amiket be akarnak vezetni, az O3D-t, a natív kódot, vagy a többszálú JavaScriptet, ez mind olyan funkció ami nem véletlen maradt ki ez utóbbi nyelvből. A canvas későbbi HTML implementációkban már támogatja a 3d-t, miért nem azt támogatják. A natív kód szépen fog futni chrome-ból, de kizárt, hogy más böngészők átvegyék mivel ellenkezik a web hagyományaival - a JavaScript forrása nyílt a HTML és a CSS kódhoz hasonlóan. A többszálú programozás menedzselése és debuggolása pedig szinte kivitelezhetetlen, vagy horrorszerű a webfejlesztők számára. Ez a nyelv egyszerűen nem erre lett kitalálva.
T0nk  
2009. okt. 06. 07:55 | válasz | #6
Na akkor a Google is végigjárja azt az utat, amit a Microsoft. Bravó.
2009. okt. 06. 06:55 | válasz | #5
Ez inkább a fejlesztőknek jó hír. A szabványtalanul összetákolt honlapok natív módban szét fognak hullani. Egy jól megírt honlap, ahol minden a helyén van, W3C követő, HTML formátumok betartása mellett szépen és gyorsan futhat.

Az O3D-re kiváncsi leszek.
2009. okt. 06. 06:29 | válasz | #4
Ezért a sematikus spongyola fogalmazásért miket fogok kapni mindjárt :S
2009. okt. 06. 06:28 | válasz | #3
Remélem nem írok nagy hülyeségeket: :D

1) A natív kód elvileg arra való, hogy a böngészőben futó cucc úgy működjön, mintha maga egy külön program volna, azaz kap normális mennyiségű erőforrást, és nem a böngészőben szaggat.
2) - 3) A platform itt szerintem kb azt jelenti, hogy abban vannak leprogramozva :D
A flash az adobe ratyisága, a javascript meg szabvány kliensoldali nyelv.
4) A számítási felhő egy neten megosztott, dinamikus erőforrásrendszer, azaz más gépen fut a cucc, ami nálad van.
5) O3D olyan cucc, amivel 3D-s megjelenítést tudsz kezelni. A google csinálta, böngészőkben kiegészítőként telepíthető.

6)
Azért jó, mert full 3d-s programokat lehet írni chrome alá, amik nem szaggatnak, mindent megcsinálnak, amit egy normál, a gépeden levő program tud. Kb ennyi.

Egyik kedvencem, bár nem google szerzemény, a Quake Live. Egy, az eredetinél szebb Quake3, csomó extrával megszórva, és böngészőben fut, folyamatosan online multiplayer játék.
Na megyek aludni :D
2009. okt. 06. 05:14 | válasz | #2
Hat kérdésem lenne közbevetőleg:

1) Mi az a natív kód?
2) Mi az a Javascript platform?
3) Mi az a Flash platform?
4) Mi az a számítási felhő?
5) Mi az az O3D platform?

6) És miért is jó ez a felhasználóknak?

Imádom az ilyen cikkeket. Mintha kínaiul olvasnám, annyit fogok fel belőle. A minap, amikor a születésnap kapcsán magukat fényezték, az sg azt mondta, hogy direkt tértek át a bulvárosabb írásmódra, mert nem csak kockák olvassák az oldalt, és közérthetőek akarnak maradni.

Hát ez most nem sikerült.
2009. okt. 06. 04:12 | válasz | #1
Na bazz..
Ha ezeket tényleg megcsinálják, hogy a fenébe maradjak a fanatikus FF-es? :O