Én is be tudom írni google-ba hogy JS OOP. Ezen a linken van is róla egész helyre kis tutorial. 2 gond van csak vele: - rögtön az elsõ bekezdésben próbál mosakodni, hogy miért is OOP - és valójában nem is az. Mivel ahhoz, hogy OOP legyen a hozzáférési szintek elég konkrétan definiáltak, hogy mik szükségesek: public, protected, private (kulcsszó nyilván lehet más). Ennek nyoma sincs. Ha valahonnan sikerül elõkaparnod egy Turbo Pascal 5.5 könyvet, mondjuk a 80-as 90-es évek fordulójáról, akkor abban korrektebb OOP megvalósítást láthatsz (vagyis ott korrektet láthatsz, JS-nél meg csak részleges próbálkozást).
"A hozzaferesi jogokrol meg csak annyit, hogy ezek elhagyasa tervezesi dontes volt, ami engem nem zavar." Pedig ez k.rvára zavaró dolog. Én dolgoztam olyan JAVA szerveren, amelyben a fejlesztõje _mindent_ public-ra vett. Ez ugye azzal járt, hogy fogalmam se volt, hogy egy osztály mely propertyje állítható, mely metódusa hívható biztonságosan kívülrõl (természetesen nem mindegyikre volt ez igaz). Éppen ez az egyik olyan érv, ami miatt én nem igazán hiszek abban, hogy a JS-ben komoly rendszereket lehetne könnyedén fejleszteni - 1 olyan változót elqr az ember, amit nem kéne, aztán keresheti hetekig hogy mitõl dõlt össze az egész.
"A static meg nem ertelmezheto egy dinamkus nyelvnel" A static az az osztály szintû változót jelölné, amely tényleg nem értelmezhetõ akkor, ha 1 osztály 1 példány.
Mivel az egesz vilag szerint OOP nyelv csak ugye szerinted nem (es a masik accod vagy jopajtasod szerint se: netperformer), azert beszurok par referenciat:
"Ráadásul ahogy látom egy "classnak" 1 példánya van, ami hát legalábbis vicces, ha így van."
Nem jol latod. Egyszeruen csak nem erted a dinamikus kornyezetek mukodeset. A lenyeg, mint a smalltalk eseten az, hogy minden objektum tipus is egyben. A hozzaferesi jogokrol meg csak annyit, hogy ezek elhagyasa tervezesi dontes volt, ami engem nem zavar. A static meg nem ertelmezheto egy dinamkus nyelvnel, csak a statikus tipus ellenorzeses nyelvekben hasznalhato. Hasonlo nem tisztan oop dontes volt c++ eseten a proceduralis c megtartasa vagy java-ban a nativ tipusok. JS eseten a vegrehajto motort probaltak vele egyszerusiteni es gyorsitani. Mondjuk c++-ban sem sokat er a const kulcsszo, mert cast-tal felulirhato. Innentol erdemesebb inkabb a fejlesztok jozan eszere hagyatkozni.
En is joreszt oop-nak nevezheto kornyezetben dolgozom (java, c++), de attol meg nem kedvelem oket annyira. A c++ ujabban mar nem is oop, amiota az stl es a boost hasznalata elterjedt, mivel a template programozas direkt szembemegy az oop elvvel.
Egyebkent meg c-ben is lehet oop kodot irni, csak a fordito nem erolteti ra az emberre a szabalyait. Az elso c++ fordito is c-re forditott. Az oop vagy a template elv nem csak a nyelvtol fugg, hanem az azt alkalmazo progrmozo tudasatol.
Nem ide tartozik teljesen, csak ha már feljött a Quake és az WebGL. A WebGL-es kódok esetében nagy a bemeneti perifériák késleltetése, ami a rendszer felépítésébõl adódik és amivel nem lehet mit kezdeni.
Akit érdekel a webGL + JS: http://youtu.be/XAqIpGU8ZZk large-scale, high performance JS-t is megemlíti. Én nem mernék a csajjal vitatkozni... :D
Visszatérve a Quake-re, John Carmack kb háborút hirdetett a különbözõ késleltetésekkel szemben. A mostani QuakeConon a beszéde nagy részében ezzel fogalakozott kb minden szinten. Szóval hivatalos webGL kódot ne várjunk tõlük. De biztos lesz valaki, aki majd átírja a Rage kódját webGLre unalmában, ha majd nyilvánosságra hozzák. :D http://media.tojicode.com/q3bsp/ :P
Abban teljesen igazad van, hogy JS-ben nem csináltam nagy projectet (valójában kicsit sem), mivel kézbe kaptam a diplomám (14 éve) csak OOP eszközökkel fejlesztek. Mindezt úgy, hogy fõiskolán akkoriban még nem is tanítottak OOP-t, csak procedurális nyelveket (meg nem Neumanni számítógéppel is foglalkoztam akkoriban, annak a nyelve se ez, se az). Szóval mielõtt dolgozni kezdtem volna 8 évig foglalkoztam procedurális nyelvek programozásával (közép+fõsuli). Éppen ezért tisztában vagyok azoknak a nyûgjeivel, és a lehetõségeivel. Nem a levegõbe beszélek, amikor azt mondom, hogy nagy projectre OOP nyelv való (vagy mocskos sok pénz+idõ, ha procedurálist választunk). Egyébként nagyobb projectek esetén a procedurális nyelveknél is próbálnak OOP felé konvergálni - dinamikus függvényhívás, és társai mind-mind OOP pótlékok. Szóval nem arról van szó, hogy csak OOP-t ismerek - ha valaki megfizetné, tudnék programozni akár Assemblyben is, hisz éveken át az volt a hobbym. Csak ma már erre nem nagyon van kereslet.
Mivel JS-t nem ismerem eléggé, ezért kértem, hogy mutassatok JS-ben példát az öröklõdésre, illetve a metódusok/propertyk nyilvánosságára/zártságára, és az absztrakcióra. Mivel OOPhez ezek kellenek. Semmi ilyesmit nem láttam. Evvan.
OK latom nincs ertelme vitazni, ha akarod felhuzom a tudasod javaban priviben arra a szintre hogy megertsd, es akkor bebizonyitom neked. Mellesleg pont rad vall hogy magyar egyetemen vegeztel es ezert nem latod at a dolgokat es valoszinu nagyobb projekteket sem csinaltal ebben a nyelvkornyezetben.
"A js pedig igen is oop." Nem tudom ezt honnan szeditek, meg hol tanítanak ilyen hülyeségeket, de ha netán egyetemen, akkor már érthetõ hogy milyen gyenge emberek jelentkeznek manapság fejlesztõnek.
JAVA téma: A JAVA készítõi egyszerûen csak nem akartak belehalni a szépségbe. Csináltak egy Integer típust, aminek van toString() metódusa, de mocsok lassú, mivel a példányosítása az ugye pointerek létrehozásával jár. Meg csináltak egy int típust, ami simán csak 4 byte a memóriában (64 bites rendszeren talán 8 byte?), és emiatt gyors - versenyképes mondjuk egy C++-al is (nem 20x lassabb, hanem 2x, nem 20x memóriát foglal, hanem 2x).
Amit írtál JS kódot abban meg se hozzáférhetõség, se öröklõdés nincs. Én nem véletlenül írtam a private/protected/public, illetve static elõtagokat. Azok fontosak. Te semmi mást nem csináltál mint egy hash tömbnek adtál függvény típusú propertyket, vagyis nálad minden public. Ráadásul ahogy látom egy "classnak" 1 példánya van, ami hát legalábbis vicces, ha így van.
Az OOP ereje pont a hozzáférhetõségbõl és az öröklésbõl adódik - a többi csak hab a tortán. Ezek segítségével egyrészt lezárható a kódok azon része, amihez kívülrõl nem szabad piszkálni (mert mondjuk még csomó minden mást is meg kéne csinálni, ha mondjuk azt a változót átírjuk), illetve biztosított, hogy ha egy kódhoz már csak egy kicsi hiányzik, akkor se kelljen providenthez fordulni, hanem simán származtathatunk belõle egyet, és a public/protected részeit piszkálva hozzáírhatjuk azt a kicsit, amit mi szeretnénk, az eredeti funkcionalitást megtartva. Ettõl OOP az OOP, ez az amiért 15-20 éve nagyobb projecteknél OOP alapon gondolkozik mindenki. Ez nyilván nem jelenti azt, hogy mondjuk JS-ben ne lehetne sok mindent megírni - ha sok az erõforrás, akkor akár nagyobb alkalmazásokat is - egyszerûen csak ahogy bonyolódik a feladat, a JS úgy válik egyre alkalmatlanabbá a megoldására.
Jól van paraszt! Vedd elõ a szifonod azt' futtasd rajta WebGL-ben a quake-t, aztán ordibáld az utcán, hogy miért ilyen lassú a JS. Csak gratulálni tudok neked! Komolyan, honnan jön ez a sok idióta?
Nem a szintaxisrol van szo, hanem arrol, hogy a java belul (a runtime motorban) mashogy kezeli az int-eket es az Integer-eket. Az egyik nativ tipuskent van kezelve, a masik objektumkent. A nativ tipusok lete eleve egy kivetel, mivel tiszta oop nyelven nincs ilyen. Tehat a 2.toString()-nek is mukodnie kellene. Java eseten a nagyobb sebesseg miatt ezt a tudast kisporoltak. Ezert lehet java-ban nagyon egyszeruen proceduralis kodot irni. Az android forrasa tele van jo peldakkal.
A javascript-es kod nagyjabol trivialis: (adatrejtes es statikus valtozok nincsennek, a javascript egy teljesen dinamikus oo nyelv)
Na vegyél vissza paraszt! Ha egy alkalmazást akarsz futtatni rajta, akkor azt nem JSbe kódolva futtatod... nyilvánvaló. Ha meg JS-ben akarsz quake livolni "irónia on", akkor nyilván nem a szaros telefonoddal kell nekiállnod. Paraszt.
JAVA int példa nagyon rossz. Attól hogy valamiben nem úgy lehet összeadni kettõt meg kettõt, hogy Integer b=new Integer(2).add(2) hanem int b=2+2 attól a nyelv csak használható (sebességû) lesz, de nem veszíti el az OOP mivoltát.
Viszont nézzünk egy apró OOP kódot - ezt hogy valósítanád meg JS-ben? Azért AS3 a kód, mert az AS1 ugyanarra az ECMA-262 szabványra épült (ezelõtt 15 évvel) mint a JS. De írhattam volna JAVA-ban vagy C#-ban is - aki bármely nyelvet ismeri, az láthatja, hogy minimálisak a különbségek: function/var töröl, :int a sor végén helyett int a sor elejére - szóval csupa apróság. Komolyan érdekelne hogy mindez hogy nézne ki JS-ben szerinted. És most légyszi ne 200 sor wikipédiás technoblablát, hanem konkrét kódot prezentálj.
Parent.as: package { public class Base { private static var nextId:int=1; protected var id:int; public function Base() { id=nextId++; } protected function calc( value:int ):int { return 2*value; } public function get value():int { return calc( id ); } } } Child.as package { public class Child extends Base { override protected function calc( value:int ):int { return super.calc( value )+1; } } } A fõprogram (Main.as): package { import flash.display.MovieClip; public class Main extends MovieClip { var c:Child=new Child(); var p:Parent=new Parent(); trace( c.id ) // Fordítási hiba - innen nem látható trace( c.calc( 1 ) ); // Fordítási hiba - innen nem látható trace( c.value ); // (2*1)+1=3 trace( p.value ); // (2*2)=4 } }
> Hagyjátok már ezt a hülyeséget. JS a scriptnyelvek közt erõsen objektum orientált, mivel objektumokkal kezel mindent. Mi más lenne, procedurális?
Már megírtam: objektum alapú nyelv. (prototype language -nek is hívják). De nem szükséges érzelmi töltést társítani hozzá. Attól még hogy nem tiszta OOP, nem "rossz". Sõt. A JavaScript az egyetlen olyan nyelv, ami platformtól függetlenül vékony kliens gépeken izolált környezetben tud futni. Mert tényleg az összes platformon fut (ahol van böngészõ), és tényleg izolált/biztonságos környezetben fut. Ebben nincs vetélytársa.
Mellesleg a JavaScript eléggé funkcionális nyelv is, ezen kívül imperatív és reflektív. Ha valakit ennyire érdekel akkor olvasson el errõl egy könyvet, és miután megismert legalább 15 nyelvet, meg a lehetséges osztályozási szempontokat, akkor egyrészt rá fog jönni hogy nagyon ritkán lehet egy nyelvre tisztán rámondani hogy ez pontosan egy adott osztályba tartozik. (De ez nem is fontos.) Másrészt rá fog jönni hogy az OOP nem mindig egyenlõ a "jó" fogalmával, és a "nem OOP" sem egyenlõ a "rossz" fogalmával. Az éppen aktuális problémától függ hogy mit érdemes rá használni.
A HTML5 pedig igenis jó! Mert böngészõ mindenhol van, és mindenhol lesz is. A népszerû böngészõk úgyis támogatni fogják. A vékony kliensek / cloud alkalmazások fejlesztésénél továbbra is ez lesz az elsõdleges kliens platform. És ebbe az irányba halad a világ, úgyhogy nem lehet megkerülni. Az már igaz, hogy egy "kicsit" lassan halad a szabványosítás, de ezt a részét nem érdemes kívülállóként bírálni. Mert az nem segít. Ha valakit ennyire zavar akkor jelentkezzen ingyenmunkára a W3C-nél.
Hagyjátok már ezt a hülyeséget. JS a scriptnyelvek közt erõsen objektum orientált, mivel objektumokkal kezel mindent. Mi más lenne, procedurális? Na mennyetek a francba xD Persze hogy nem OOP, mert nem programnyelv, de alábecsülni viszont nem érdemes, mert egy két alap funkció hiányától eltekintve szinte mindent meglehet vele valósítani. Úgy értem sokkal szélesebb a felhasználási köre, mint az sokan hinnék.
Egyébként bevallom õszintén betegnek tekintek mindenkit, aki az OOP-vel dobálózik, mert kit érdekel, ha pl egy nyelven OOP-vel fejlesztesz vagy nem? Õszintén? A lényeg a moduláris fejlesztés, azt meg olyan módszerrel meg adatstruktúrába kivitelezed amilyennel akarod.
"a JS nem OOP"
Mindenesetre objektum orientaltabb mint a c++. Egyebkent ilyen alapon a java sem az, mivel kezeli a c-bol atvett proceduralis megkozelitest es vannak benne nativ tipusok is, amik nem objektumok. (pl. az int nem objektum, az Integer igen, mindketto megtalalhato a java-ban)
Egyebkent nem kell objektumorientaltnak lennie egy nyelvnek ahhoz, hogy mukodjon. Tipikus pelda a c++-os template-ek esete, amik sok mindenek, de nem objektumok es kifejezetten megtorik az objektumorientaltsagot. (pl. template container-ekbol nem lehet szarmaztatni, raadasul szandekosan lettek ilyenek)
A javascript egyebkent nem olyan rossz nyelv. A html-bol szarmazo objektum faval pedig egesz jol hasznalhato egyszerubb feladatokra. Persze van jobb, pl. a nativ java, ami a legtobb uzleti rendszert es az osszes android-os keszuleket hajtja. Ott is megtalalhato az objektumfa, csak html helyett xml alapu, viszont ugyanugy egy bongeszo motor rendereli. (az android osszes gui-ja gyakorlatilag egy-egy bongeszo ablakban fut) Mellekhataskent felbontasfuggetlenek az alkalmazasok. Tehat azt amit az iphone eseten 3 kepernyomerettel nem tudnak rendesen kezelni, azt az android x+sok kepernyofelbontassal is jol kezeli, alapbol. (by design)
Az oop-vel kapcsolatban egy megjegyzes: Szerintem a smalltalk a legtisztabb oop nyelv, ott minden objektum peldany egyben sajat maga prototipusa is. Tehat egy objektum kepes magabol csinalni egy uj peldanyt, amit utanna szabadon fejleszthetunk. Ettol meg a szulo objektum marad es mellette egy leszarmaztatott objektumma valik. Tehat egy peldanyra ragaszthatunk egy uj valtozot vagy metodust es ezzel mar le is szarmaztattuk es hasznalhatjuk uj peldany letrehozasara. Sokkal egyszerubb es dinamikusabb mint a legtobb csak statikus tipusokat kezelo nyelv (pl. c++). A java ilyen szempontbol a ketto kozott van, mert van statikus tipus kezeles de lehet dinamikusan is kezelni (csak az bonyolult). Az android pl. mindkettot hasznalja meg a gui-ban is. (klasszikus eset: haromfelekeppen lehet egy gombra esemenykezelot rakni, egy statikus, egy dinamikus es egy runtime reflexiv modon, a harmadikat a legegyszerubb hasznalni es a legbonyolultabb volt a rendszer iroinak mogerakni a support kodot)
"JAVA szerver oldalra való, ott jól is érzi magát. Esetleg desktop kliensnek is alkalmas, ha nem zavar senkit a 3x memória fogyasztás, és 10x sebesség deficit ami mondjuk egy natívhoz képest szokott lenni."
Ezert is jo a jit-es forditott java. Az oracle fele verzio jit-elve csak 2x lassabb, mig a google fele verzio mar egyaltalan nem lassabb, mivel eleve nativ gepikodra forditanak. (arm vagy x86-os utasitasokra) A vicces az, hogy a ket rendszer atjarhato, de az oracle jogi okok miatt nem engedi.
Egyebkent bongeszobe szerintem a legjobb az android support lenne. Tehat ha az android-os alkalmazasok kepesek lennenek bongeszoben futni (akar html oldalba agyazva is), akkor nagyjabol hasznalhato lenne a technologia. Az android fele java api sokkal konnyebben hasznalhato es fejlettebb mint az oracle fele desktop java, raadasul hordozhato is. Mint ahogy android alatt egy java-s kod eleri a html oldalak objektum modelljet, ugy egy bongeszoben is a html oldalak alatt lehetne javascript helyett java. Tehat java programnyelv, de html-es gui-val. Android alatt meg a hozzaferesi jogok kezeleset is megoldottak, tehat egy adott alkalmazas (vagy oldal) kerhet es kaphat egyedi jogokat, viszont a felhasznalok dontik el, hogy mit engednek es mit nem. (pl. egy jatek tolem nem fog cimlista hozzaferest vagy hivas inditasi jogot kapni, de webkamera es audio felvetel jogot sem)
És akkor már nem bukott meg? Ezek a banki szoftverek tizenX éve készültek, nem cserélik le õket egyik napról a másikra. Más kérdés, hogy van aki pont a JAVA-s ebank miatt váltott számlavezetõ bankot, mivel az internetet is használó böngészõben már tiltólistán van (tudom, azóta javították, de van újabb hiba), 2 böngészõt meg azért használni, mert egyikkel bankol, másikkal meg böngész az egyszerûen kényelmetlen.
JAVA szerver oldalra való, ott jól is érzi magát. Esetleg desktop kliensnek is alkalmas, ha nem zavar senkit a 3x memória fogyasztás, és 10x sebesség deficit ami mondjuk egy natívhoz képest szokott lenni.
> Az meg hogy a html5 hozzáférjen a HDD-hez - erre mondják vidéken, hogy az b.szna be. Egyébként a java applet pont ilyen volt (na jó, kellett hozzá egy hamisított tanúsítvány is), és ez volt az egyik oka, hogy megbukott.
A java applet nem bukott meg. Tovább él JNLB (a la "java web start") formájában, és egész komoly cégek épülnek rá. Pl. banki rendszerek is.
> OOP eleve ott kezdõdik, hogy típusos a nyelv. Anélkül nemhogy több, hanem pontosan nulla OOP kritériumnak felelhet meg.
A típusosság és az osztályok megléte két különbözõ dolog.
Típusosság szempontjából vannak erõsen típusos nyelvek, nem típusos nyelvek és gyengén típusos nyelvek (pl. objective c). Vannak keverékek és átmenetek is. Pl. object pascal nagyjából szigorúan típusos, de a szám típusú értékeket tudja keverni. Vagy van úgynevezett "duck-typing" ami azt mondja hogy "minden ami hápog az kacsa" (pl. Python).
Az "objektum orientáltság" feltétele az osztályok megléte és az öröklõdés. Más kritériumok: egységbe zárás, és (jobb esetben) polimorfizmus. Ezeknek eleget tevõ nyelvek objektum orientáltak.
Az már igaz, hogy több a típusos (és gyengén típusos) objektum orientált nyelv. De létezik nem típusos OOP nyelv is.
A JavaScript az konkrétan egyik kategóriába sem tartozik. A JavaScript az egy úgynevezett "objektum alapú" nyelv. Azért nem objektum orientált, mert hiányoznak belõle az osztályok. (Vannak benne beépített prototípusok, de valójában azok sem osztályok hanem objektumok.) Nincs benne rendes ("nagy könyv szerinti") öröklõdés sem. Csak objektumok vannak, viszont azok megvalósítják az egységbe zárást, és (kicsit nyögve nyelõsen) a polimorfizmust is.
Érdekes dolog például a smalltalk esete. A SmallTalk-ban vannak osztályok, de az osztályok is objektumok, és azoknak is van osztálya ami szintén objektum... Itt az a döntõ, hogy létezik egy "o objektum A osztály példánya" reláció. Tehát mivel a nyelv definiálja az "osztály" fogalmát mint olyan, ezért objektum orientáltnak mondható.
A JavaScript nem definiál osztályokat, csak prototype-okat, de azok is csak objektumok.
További módokon is lehet oszályozni nyelveket. Például: tisztán objektum orientált: csak objektumok vannak benne. A SmallTalk ilyen. Vegyes/kevert nyelv: van benne más programozási eszköz is, nem csak objektum. Pl. Pascal vagy C++ ilyen (van benne eljárás és függvény is).
Szóval mielõtt ilyen elhamarkodott kijelentésekkel összezavarsz másokat, legalább nézz utána.
Melóhelyen volt szerencsém HTML5-ben canvasos, javascript OOP (ha valakinek úgy tetszik hash tömbös) online bögészõs albumszerkesztõ szoftveren dolgozni és kifejezetten pozitívak a tapasztalataim. Könnyû debuggolni, felbontás, böngészõ és platfom független. Elismerem hogy tesztelni kell minden böngészõ és eszköz alatt, lehetnek eltérõségek amik néhány sorral orvosolhatóak, de legalább nem kell újraírni az egészet. Akinek nem tetszik használjon flasht, javat, silverlightot vagy amit akar
Attól hogy egy nyelvben a hash tömböt elnevezzük Objectnek, attól még nem lesz OOP. OOP eleve ott kezdõdik, hogy típusos a nyelv. Anélkül nemhogy több, hanem pontosan nulla OOP kritériumnak felelhet meg.
Az meg hogy a html5 hozzáférjen a HDD-hez - erre mondják vidéken, hogy az b.szna be. Egyébként a java applet pont ilyen volt (na jó, kellett hozzá egy hamisított tanúsítvány is), és ez volt az egyik oka, hogy megbukott.
javascript ? Lehet, hogy nem felel meg több OOP kritériumnak. pl nincs benne öröklõdés (valamennyire áthidalható). De attól még zsírosan objektumokra épül. Én nem merném rá azt mondani, hogy nem OOP.
A HTML5-ben egyébként az a legnagyobb hiba, hogy nem engedték hogy hozzáférjen a teljes HDDhez. Pedig biztonsági szempontból meg lehetett volna oldani...
Jó lenne ha egy ilyen mögé jobban odaállna a google. A Chrome már így is majdnem egy komplett virtuális gép. Érdemes megnézni hogy miket építettek már V8 javascript engine-jükre. Pl nodejs. Jobban kéne neki ezt a desktop alkalmazás vonalat nyomni a HTML5-tõl függetlenül is.
FB elnöke éppen ma nyilatkozta, hogy a FB legnagyobb hibája volt a html5-ös kliens erõltetése mobil eszközön. Az hogy egy leíró nyelv, amelynek bizonyos részeit egy interpretált nem OOP scriptnyelv baszkurálja az minden, csak nem elõremutató. Meg persze nem is böngészõfüggetlen, mert a fele böngészõgyártó a W3C mögé állt, fele meg a WHATWG mögé, szóval lóf.sz lesz ebbõl, nem egységes szabvány.
A fõ gond, hogy a w3c kb úgy mûködik, mint egy sóhivatal, és a böngészõgyártók megint ráuntak a tökölésre - mellesleg jogosan. Ha a W3C kicsit normálisabb sebességgel dolgozna már rég nem ezen rágódnánk, nem kellene 3 sok ugyanahoz hogy minden böngészõn jó legyen, stb. Vicc ez az egész "hivatal" dolog és nem csak itthon.
Minden szabvány fõleg ha bonyolult (komplex) nyögvenyelõsen születik. A részeirõl sokszor csak a gyakorlat dönti el hogy jó/rossz vagy egyáltalán nem is kell, viszont itt ott ki kell egészíteni. Aztán egyszer csak beindul hirtelen mûködni kezd...de addíg számtalan visszacsatolás kell a fejlesztõi közösségektõl. Nem úgy van az, hogy összeülnek az okosok 1-2 évet tanácskoznak és utána kihirdetik a tutit, azt mindenki mehet dolgozni vele.
Nehéz megtanulni az új dolgokat és lépést tartani a fejlõdéssel mi? Microsoft is maradhatott volna 3.1-nél ennyi erõvel
"aztán parádézzon a sok szerencsétlen, sõt, miért nem tesznek bele mp3 lejátszót is? Kész is a HTML6!"
Van benne mp3 lejatszo. Az opera peldaul mar eleve ezzel jeleniti meg a wikipeidan levo hanganyagokat. De a youtube is flash nelkuli nativ html5-ben adja a videokat ha kikapcsoljuk a plugin-okat. Meg nem tokeletes, de mar szabvanyos es mukodik. Igazabol semmivel nem tud tobbet mint anno egy netscape 4-es, de mindezt szabvanyosan.
Nem értem a fikázást, a html5 egy olyan böngészõfüggetlen nyílt technológia amit képes (lesz) lefuttatni bármilyen okostelefon, tábla, pc, konzol, kenyérsütõ. Használható alternatívát kínálva a flash, objective-c, java és sok más szar helyett, lerövidítve ezzel a fejlesztési és portolási intervallumot.
Jaja maradjon inkább a flash, mert az nem elavu.... izé...
Meg a jó nagy tudod mi avult el :D Erre a retek HTML5-re sincs nagyon szükség, csak erõlködnek mint a fábaszorult :D Annó amire kitalálták a HTML, XHTML szabványokat arra teljesen jó és korrektek a régi szabványok. Jelölik a dokumentumokat úgy ahogyan kell. Ja hogy pillangók röpködjenek a böngészõbe kerestül kasul, meg bejöjjön a szuper quake 2012 a böngészõbe a hiper szuper webgl szarjukkal? :D Inkább tartsák meg maguknak. Vagy jobb ötlet lenne, ha microsoft kiadna egy IE Live+ szolgáltatást, aminek segítségével bekerül mindenféle JS plugin meg webgl hülyeség, aztán parádézzon a sok szerencsétlen, sõt, miért nem tesznek bele mp3 lejátszót is? Kész is a HTML6!
Informatika és tudomány
