49
-
Sir Ny #49 "adobe acrobat"
adobe acrobat, mint netes programnyelv? -
lordofchaos #48 Pontosan, és ez így van jól. Van verseny, lehet választani. Olyan, hogy tökéletes nincsen. -
kvp #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. -
lordofchaos #46 Használjatok Rubyt! :P -
Mcsiv #45 de ettől nem lett jobb a nyelv, csak még kaotikusabb;] -
carstep #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 :-). -
Alfa Of NS #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. -
johnsmitheger #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 #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.... -
#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 -
valentine2 #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 -
Utokverek #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! -
#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 #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 #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. -
A1274815 #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. -
Drawain #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 #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;] -
A1274815 #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 #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." -
#29
guglinak lehet jelentkezni egy sallerért, mert ez a natív izé ez faszság. -
johnsmitheger #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... -
A1274815 #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 #26 én is Utókeveréknek olvastam :D -
Mcsiv #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 #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 #23 NaCl = konyhasó 
-
Würth #22 Ez a verzió már tud alapból reklámokat blokkolni ? ( lehet hülye kérdés volt 
)
-
roliika #21 Ráadásul eszesz-eket írtál utána. :DDD -
roliika #20 
-
#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 -
#18
"Az első feladatot a Native Client, rövidebb nevén a NaCl végzi majd"
NÁCI??? Ez dejó :SSSS -
kvp #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 #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 #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. -
moikboy #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 #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 #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 -
roliika #11 "Vagy a Google most Mátrixot tervez" <- Kitelik tőlük, figyeld meg. -
Crane #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