ALERT!  

Kockarovat. Aki nem kocka, annak talán uncsi lehet. ;)

Így nyáron, amikor van időm olyan mélységben is beleásni magam egyes technológiákba, mely már jócskán túlmutat egy elfogadható egyetemi gyakorlati jegy követelményein, kezdek egyre inkább ráébredni arra, hogy egyes, központilag meghatározott szabványok sokszor csupán elméleti irányjelzőként működnek.

Amikor Grespik Lászlót a jogi kamara fegyelmi eljárás alá vonta, amiért meg merte kérdezni egy bírótól, nem-e zsidó (akkor ugyanis elfogultnak számított volna a konkrét perben), azzal a tanulsággal zárult az ügy, hogy az etikai kódex csupán fából vaskarika. A webfejlesztésben sokszor ugyanez a helyzet a hivatalos W3C specifikációk témájában.

Az, hogy rengeteg CSS megoldást nem lehet Internet Explorer alatt alkalmazni (bár ez IE7 alatt sokat javult), és sokszor még a Firefox működése sem felel meg a specifikáció követelményeinek, közismert. Nincs mese, az ember jobban teszi, ha olyan nyelvi elemek használatára szorítkozik, melyek működése a legtöbb böngészőben hasonló végeredményt produkál, vagy legalábbis úgy építi fel az oldalmegjelenítést, hogy a W3C ajánláshoz közelebb álló funkciók csupán alternatív extraként, parasztvakító csiliviliként legyenek jelen.

Az viszont, hogy milyen szarakodás megy a JavaScript nyelv körül, már tényleg röhejes. Olyan, hogy valamelyik böngésző értelmezője pontosan megfeleljen az ECMA-262 leírásnak, nem létezik. Mindenki ehhez igazítja a saját megoldását, de mindenki másként nevezi el. A Microsoft például, amióta ki lett tiltva az alapértelmezetten telepített Java a Windows XP-ből, úgy utálja a Sun-t, mint a szart, így a saját terminológiájában még véletlenül sem használ konkurens technikákra utaló kifejezést (java). Nála tehát jscript-ről beszélünk.

Persze szép és jó lenne az életünk, ha csupán az elnevezésben lennének ilyen különcségek, de nincs ilyen szerencsénk. Amikor valamelyik csoportnál (akár a Microsoft-nál, akár a Mozilla együttműködő fejlesztőinél) megfogalmazódik egy új ötlet, beleépítik a saját verziójukba, és meghirdetik, hogy hű, milyen jó ez így. Ezt pedig látja a konkurencia is, ezért ő is megírja ugyanazt a saját rendszere alá, amely így, bár közel azonosan működik, de néhány metódusban különbözik, nehogy valaki lopással vádolhassa őket.

Csak akkor működik mindenhol, ha sokat szarakodsz veleA webfejlesztők szempontjából ez a sok "apró" eltérés úgy jelenik meg, hogy a munka nagy része nem egy adott böngésző alatti működőképességre koncentrálódik, hanem a lassan könyvtárnyi terjedelmet elfoglaló, teljesen értelmetlen különbözőségek menedzselésére. Így egy széleskörűen működőképes kód úgy néz ki, hogy egy rakás try - catch blokk, illetve egyéb hibakezelési megoldások vannak egymásba ágyazva, abban a reményben, hogy akármilyen egzotikus dzsunga böngészőt is használ a júzer, a sokadik kivételkezelés után csak lesz egy pont, ahol nála is hajlandó működni a cucc.

A slusszpoén ebből egyenesen következik. Mivel a verzióháború manuális kezelgetése erősem a produktivitás rovására megy, amely ("rohanó világunkban, ahol az idő pénz, bla bla bla") jelentős hátrányt jelent a fejlesztőcégeknek, így az igazi megoldást ilyenkor az olyan, előre megírt függvénykönyvtárak használata jelenti, mint amilyen például a Script.aculo.us.

Az egyetlen probléma ezzel, hogy ekkor nem központi ajánlások minél pontosabb követésére fordítod az időt, hanem helyette egy házi keretrendszer készítőinek belső logikája mentén építed fel a kódodat, mely így mindennél távolabb vezet a W3C és ECMA leírások közvetlen használatától.

Ha élni akarsz, akkor nem ragadhatsz le az etikai kódexnél - mondja Grespik. És ugyanígy a központi webajánlásoknál se. Mert a gyakorlatban mindkettő csak dísz.

By SoDI


 
 
0 (0)
Jelentkezz be a szavazáshoz!