Az AJAX mire való?

Nem teljesen értem, miért tesztek fel néhányan ilyen kérdéseket. A Google a barátod.

[link]

ha nem akarsz sokat olvasni, w3school-on röviden levan írva:

(zöld téglalap)

[link]

Vegyük például a GYK-t. Te egy adott kérdéshez írsz éppen válasz, immár vagy 5 perce. Közben jön egy új privát üzenet. De te ezt nem látod, amíg újra nem töltöd az oldalt. Ha még további 15 percig nem töltöd újra az oldalt, akkor 15 percig nem értesülsz az új üzenetről. De ha lenne AJAX használat, akkor az oldal meg tudná tenni, hogy mondjuk percenként kétszer elküld egy kérést a szerver felé, ami csak az olvasatlan üzenetek számát kérdezi le. Az erre adott válasz alapján aztán fogná a bal oldali menüben az „Üzeneteid” menüpontot, és átírná „Új üzenet! (1)”-re. Mindezt úgy, hogy közben te nem navigáltál el a honlapról, nem töltötted újra az oldalt, továbbra is írod a választ.

Mivel nem töltődött újra a teljes oldal, minden görgethető tartalom marad oda görgetve, ahogy volt, minden checkbox, radiobutton marad olyan állapotban, ahogy volt, minden szövegbeviteli mező tartalmaz marad az, ami, minden kijelölés kijelölés maradt, ahogy volt.

A másik terület, ahol jól jöhet, az az erőforrásokkal való spórolás. Ha van egy komplex honlap, akkor az oldal újratöltése után újra le kell az oldalt generálni, újra letölteni a képeket. Persze ez utóbbi esetén meg lehet oldani, hogy a képeket becache-elje a böngésző, de az sem járható út, ha a képek valamilyen okból gyorsan változnak. Ehelyett ha AJAX-szal csak azt tölti le az oldal, ami változ(hat)ott, akkor nem kell újra letölteni mindent, aztán újra értelmezi azt, hanem csak azt a részt kell újragenerálni, ami megváltozott. Kevesebb adatforgalom, kisebb terhelés a szervernek, kevesebb processzorhasználat a kliens oldalon.

#4 Pedig ez a mondat adekvátan leírja: "A weblap kis mennyiségű adatot cserél a szerverrel a háttérben, így a lapot nem kell újratölteni minden egyes alkalommal, amikor a felhasználó módosít valamit. Ez növeli a honlap interaktivitását, sebességét és használhatóságát."

Ahelyett, hogy az egész oldalt újratöltenéd (vagy betöltenél helyette egy másikat), a háttérben küldesz egy a szervernek egy kérést, így

- Az oldal (többi része) a töltés ideje alatt is használható marad

- Egy kérés kevesebb adatra vonatkozik, így gyorsabban végbe is megy

- Egyszerre több kérés feldolgozása is folyamatban lehet

- Növelhető az oldalon található elemek interaktivitása (pl. keresési javaslatok)

Ha az enyém után kapott (#3-as) válaszban javasolt W3Schools-os tutorialra rámész, az egészet egy magyarázat kíséretében kipróbálhatod, láthatod működés közben, és - remélhetőleg - nincs több kérdés. Ha meg mégis van, akkor azt a tán már érdemes is feltenni.

A fent látható kérdésed ellenben nagyjából olyan, mintha azt kérdezted volna, mire való a multithreading, az ilyesmit pedig az ember nem szereti elmagyarázni, mert az interneten mások már kismilliószor megtették, már csak meg kell guglizni.

Csak még egy példa: Mondjuk van egy elég nagy, összetett weboldalad, és rajta egy utcai webkamera képe, ami fél percenként frissül. Ha fél percenkét újratöltődne az oldal a miatt az egyetlen kép miatt, akkor a felhasználó a haját tépné, teljesen jogosan. Ezzel a módszerrel viszont a kliens le tudja kérni csak a képet, ez kíméli a klienst, szervert, hálózatot, felhasználó idegeit.

("Alap" esetben a kliens mikor szerverhez fordul, akkor egy weboldalt kérdez le, vagyis egy teljes html, css, stb. tartalmat. A fenti módszerrel ennek az adatkupacnak egy kis részét is le tudja kérni és frissíteni a már megjelenített, renderelt oldalon.)