Weblabor

A fórumban kérdés merült fel egy AJAX-szal foglalkozó könyvvel kapcsolatban, ennek apropóján szeretném megosztani a véleményemet és a tapasztalataimat a témában. Bár egyre több helyen használják a technológiát, de a felmerülő gondokkal kevés írás foglalkozik.

Jó AJAX-ot használó weboldalt/alkalmazást nehéz készíteni. Ez részben annak köszönhető, hogy az internet technológiailag rossz alapokra építkezik, valamint sokan nem fordítanak elég figyelmet a dinamikus adatcserével járó problémákra. A leggyakrabban elkövetett hibák, amelyekkel eddig találkoztam:

1. Pusztán JavaScripttel állítanak elő bizonyos tartalmakat: jó példák erre az Origó galériái. Ha magát a markupot kliensoldalon, DOM műveletekkel generálják, az egyrészt lassú, másrészt, mivel a képek nevét és elérési útvonalát ígyis-úgyis valamilyen módon (statikusan vagy dinamikusan) bele kell írni a dokumentumba, ennyi erővel helyből szerveroldalon is el lehetne készíteni a kódot, hogy a keresők, valamint a kikapcsolt JavaScripttel böngészők is meg tudják nézni az oldalt. Ez utóbbi esetben a kész markupot a megfelelő helyre innerHTML segítségével szúrják be, de ez is ellentmondásos: ha ígyis-úgyis a szerveren készül a kód, akkor pontosan mit is nyerünk az AJAX-szal? Valamennyivel kevesebb adatot kell küldeni, tehát picivel gyorsabb lesz, de ugyanezt az élményt elérhetjük cache-eléssel is (Etag, Expires fejlécek), amire amúgy is szükség van. Így inkább csak bonyolultabb kód lesz a végeredmény, mert a plusz JavaScript újabb hibázási lehetőséget hoz magával.

2. Bizonyos tartalmat csak AJAX kéréssel kapunk meg: például a HWSW cikkei alatti fórumhozzászólások. Ehhez mindegyiknél külön kéréssel fordulnak a szerver felé, ahelyett, hogy amit lehetett volna, már az elején kitették volna a HTML-be. A sávszélesség a legtöbb esetben a szűk keresztmetszet, ráadásul komolyabb rendszerek esetén sok kódnak le kell futnia addig, amíg elő tudja állítani a kimenetet (például több osztályt kell létrehozni a lekérdezéshez, amik az eredeti HTML készítésekor már eleve rendelkezésre állhattak). Ez egy minden szempontból erőforráspazarló elgondolás, zéró gyakorlati haszonnal.

3. Túl sok tartalmat generálnak AJAX segítségével:például az eRepublik adatlapjai (regisztráció szükséges). Amint leérkezett az oldal váza, a $(document).ready()-ben rögtön indítanak pár kérést, hogy néhány további szekciót feltöltsenek. Ez ugye ennyi kérés, lassúak, mint azt az előző pontban kifejtettem, ráadásul sokszor JS-sel állítják elő a markupot. Ha harmadik fél szerveréhez is fordulnak (oldalletöltések számlálása, reklámok) vagy lassú a hálózat, akkor a $(document).ready() elég későn futhat le, és az így előállított kód később villanhat be. A fentiek miatt az oldal betöltődése után rövidesen a böngésző több másodpercre „lefagy”, még görgetni sem lehet (mindezt modern browseren, pluginek nélkül).

4. Használhatósági gondok: többek között a Randivonal oldalain (regisztráció szükséges) találkoztam olyannal, hogy az AJAX-szal betöltött tartalom bizonyos paramétereit (például hol állok a listában) nem az URL-ben, hanem a munkamenetben tárolják. Így, ha egy másik fülön megnyitottam ugyanazt az oldalt, és visszaléptem az elsőre, a lista alaphelyzetbe állt. Ezek mellett sok helyen az előre-vissza gombok működése is problémát okoz, vagy frissítéskor sem azt kapom, amit várok. Vagy egy másik anomália, hogy egy cikk alatt AJAX-szal jelenítik meg a hozzászólásokat, és ha azok között ellépek az n-edik oldalra, majd megnyomom a böngésző vissza gombját, akkor mit töltsünk be: az előző hozzászólásokat vagy az előző lapot?

5. A tartalom betöltését jelző animáció: ha elég gyors a hálózat és/vagy kevés adatot kapunk, nem hordoz információt a megjelenése, így az esetek túlnyomó többségében zavaró a bevillanása. Akkor van csak jelentősége, ha nem ilyen szerencsések a körülmények, ezért én általában 1,5-2 másodperc után szoktam kitenni, hogy a felhasználó lássa, a program dolgozik. Ugyanez igaz a Flash objektumoknál is, főleg akkor, ha a betöltendő SWF már a memóriában van. Visszatérve a HTML-re, nem túl szép megoldás az sem, amikor nem adják meg a képek méreteit (még akkor sem, ha azok fixek), így egy újabb adag kép betöltésekor a tartalmi szekció „ugrál”.

Kérdések

Mielőtt AJAX-ot használó fejlesztésbe vágnánk, érdemes feltenni pár kérdést.

• Segíthet-e ez a technológia, és ha igen, miben?
• Mennyit nyerhetünk vele?
• Mennyit veszthetünk vele (pl. bonyolultabb kód, nehezebb karbantartás)?
• Mik az alternatívák? (Például fix méretű tartalom esetén egy <iframe> használatával egy plusz sort sem kell kliensoldalon írnunk)
• Milyen használhatósági (usability) problémák merülhetnek fel?
• Meg tudom-e oldani a feladatot a célközönség által használt minden böngészőverzióban?

Ezek mellett nem szabad elfelejtkezni két kisebb csoportról: ha fogyatékkal élő látogatja meg oldalunkat, ő is tudja majd használni? Ő is be tud regisztrálni, be tud jelentkezni? Ha dinamikusan frissítem a tartalmat, miből fogja tudni, mi az, ami változott? A másik csoportba azok az emberek tartoznak, akik biztonsági okokból kikapcsolják a JavaScriptet, mert tudják, hogy a legtöbb támadást ennek a segítségével indítják.

Arról sem szabad elfelejtkezni, hogy a fejlesztők többsége nagytudású, sokszor Java alapú IDE-t használ, amelyek nem a gyorsaságukról híresek, emiatt kénytelenek az átlagnál erősebb hardveren dolgozni. Ez a tény, valamint az, hogy helyi hálózaton tesztelnek, elfeledtetheti velük azt, hogy az átlagfelhasználó messze nem rendelkezik ilyen feltételekkel. Nem ritka, hogy tíz-tizenöt szkriptet is betöltenek, biztos, hogy erre mind szükség van?

Mivel a gazdasági válságból még messze nem keveredtünk ki, ami ráadásul hazánkat még jobban érintette kiszolgáltatott helyzete miatt, technológiailag a konzervitizmus kifizetődőbb lehet. Ez különösen igaz olyan oldalaknál, amelyekből a megrendelőnek közvetlen vagy közvetett haszna van, s most különösen fontos, hogy mindenkit megfogjunk. Ne felejtsük: a weben a belépési és az elhagyási küszöb alacsony, azaz, ha valami nem úgy működik, nem azt kapják az emberek, amit elvárnának, nagyon könnyen továbbmehetnek a konkurenciához. Egy százaléknyi látogató elvesztése az internetről generált bevételt ugyanilyen mértékben csökkenti, így a sitebuildernek célszerű kétszer is meggondolni, milyen újítást szabad bevezetni, mert ez a kiesés az ő felelőssége. A cél nem feltétlenül az, hogy oldalunk látványos legyen, hanem hogy lehetőleg mindenkinél jól jelenjen meg, és jól működjön.

Kell-e?

Nem tudom, létezik-e, létezhet-e olyan weboldal vagy webes alkalmazás, ahol egyáltalán meg lehet oldani a teljesen dinamikus adatfrissítést, azaz azt, hogy ha megváltozik bármilyen állapot, mint az 4-es példában, vagy mondjuk az adatbázis bizonyos táblái módosulnak, akkor a kapcsolódó klienseknél, ahol ez szükséges, automatikusan frissítsük a megfelelő részeket (akár több megnyitott fülön). Ehhez rengeteg információt el kell tárolni a szerveren, ami eddig az URL-ben volt, vagy integrálni kell az alkalmazást az adatbázis motorjába, hogy értesüljünk a minket érintő eseményekről.

Mivel sem szabvány-, sem pedig böngészőoldalról nincs támogatása a dinamikusan frissülő tartalmaknak, jelenleg AJAX-ot használni weblapon nem tanácsolnám senkinek, mert annyit nem nyerünk vele, valamint egyszerűen annyi hibázási lehetőség van, ráadásul a technológiát használó oldalak és segédletek is szinte csak rossz példákat tudnak hozni. Egy webes alkalmazás már más tészta, de saját tapasztalatból tudom, hogy ott is óriási kihívás olyan backendet készíteni, amivel normális felhasználói élményt adhatunk a kliensen, hacsak nem lehetetlen.