Siden Tim Berners-Lee i begyndelsen af 1990'erne skrev det første udkast til HTML og HTTP-protokollen, har WWW udviklet sig med dramatisk hast. Det, der begyndte som et paragraf- og tabelværk til opstilling og deling af videnskabelige data, har i dag udviklet sig til en kompleks platform for alt fra vidensdeling over b2b-relationer til personlig partnersøgning og ren underholdning. Aldrig før i historien har vi set en ny teknologi blive så hurtigt og så dybt integreret i vores liv og samværsformer.
Selvom WWW er blevet så omfattende og dybt forankret i vores kultur, befinder teknologien sig stadig på mange måder på blestadiet. Områderne, vi bruger WWW på, breder sig dag for dag - og der synes ikke at være grænser for, hvad vi kan finde på at udveksle via nettet. Ikke desto mindre hænger vi stadig fast i mange af de oprindelige teknikker fra begyndelsen af 90'erne. Teknikker, som kan være ganske udmærkede, hvis man vil søge viden om, hvad andre indenfor ens forskningsområde er nået frem til - men som er helt utilstrækkelige for mange af de måder, vi bruger nettet på i dag.
Med CGI, ASP, PHP og forskellige databaser blev der mulighed for at skrive dynamiske websider og komplekse webapplikationer. Ved f.eks. en nyhedsportal fungerer disse teknologier fint i forbindelse med HTML med tilhørende hyperlinks og formularer. Sideskiftet - der opstår, når man trykker på et link til en nyhed - minder lidt om det at bladre hen til en bestemt side i en avis. Oplevelsen modsvarer det kendte - blot en anelse langsommere og uden gener i væsentlig grad.
Ved egentlige applikationer er 'de gamle' navigationsmetoder derimod ikke særligt velegnede. I sammenligning med et almindeligt Windows program er en traditionel webapplikation således ofte ulideligt langsom, og de mange 'blanke perioder' i interfacet - der opstår som følge af de uundgåelige sideskift - får endvidere applikationen til at virke skrøbelig og ustabil.
Synkron kommunikation
Ved synkron kommunikation mellem browser og server forstås 'den gamle' navigations metode, hvor brugeren trykker på et link eller sender en formular og herved udløser en HTTP-forespørgsel til en web-server. Serveren modtager evt. medsendte data - kalder måske på en database - inkluderer eksterne dokumenter, m.m. - for til sidst at returnere en komplet HTML-side til browseren, som denne så fortolker og viser.
Fra det øjeblik brugeren foretager sin handling og til det øjeblik, hvor den nye side vises, har hun ikke andet at lave end at se på en timeglas-cursor og en hvid browser. Synkron kommunikation er med andre ord kendetegnet ved gentagne brugerhandlinger og resultatet af disse er adskilt af passive, uproduktive og ofte irriterende lange pauser.
Asynkron kommunikation
Ved asynkron kommunikation fjernes interfacet ikke 'under fingrene' på brugeren, så snart hun foretager en handling. HTTP-forspørgslen foretages i baggrunden, mens brugeren yderligere kan interagere med interfacet og evt. foretage flere forespørgsler til serveren. Serveren behandler medsendte data ligesom ved synkron kommunikation, men i stedet for at udskrive en hel HTML-side, udskriver den de rå data som XML eller JSON (JavaScript Object Notation) og sender dem retur til browseren.
Resultaterne af de enkelte forespørgsler behandles af browseren, efterhånden som de returnerer, og nye HTML-elementer med de returnerede data fra serveren indsættes i browserens HTML-side.
I visse situationer kan der naturligvis være logiske grunde til at afholde brugeren fra at foretage flere af en bestemt slags handlinger, før resultatet af en given forespørgsel er returneret og vist - men ellers er der intet i vejen for at have flere eller mange forespørgsler i luften ad gangen.
Asynkron kommunikation mellem klient og server er langt mere glidende og programagtig. Der opstår naturligvis stadig pauser mellem brugerhandlingen og det øjeblik, resultatet vises, men dels kan brugeren foretage sig noget fornuftigt i mellemtiden og dels skal serveren udskrive mindre kode (og mindre kode skal derfor transporteres mellem server og browser), hvorfor pauserne alt i alt opleves betydeligt kortere.
Små, forsigtige skridt på vejen
Lige siden slutningen af 90'erne, da ASP og PHP blev hvermands eje, har vi som webprogrammører stræbt efter at gøre vores webapplikationer så programagtige som muligt. Ikke mindst CMS'er og script-chats har i årenes løb været genstand for mange fantasifulde løsningsmodeller på asynkron serverkommunikation.
Et eksempel herpå er de velkendte 'iframe-chats' i JavaScript og PHP eller ASP. I sin enkleste form består den af en formular med et tekstfelt og en knap, samt en tabel til visning af beskeder. I dokumentet ligger også en skjult iframe, hvis navn sættes som formens target. Hver gang brugeren sender en besked til serveren, er det derfor ikke hele siden, der opdaterer, men kun dokumentet i iframe'en. Derved kan man sætte beskeder ind i databasen på serveren - 'i baggrunden' og uden skærmbilledet 'blinker'. I princippet ser koden sådan ud:
Se figur 1
Samtidig reloader dokumentet i iframeen sig selv med passende intervaller - f.eks. hvert 10. sekund. Hvergang dokumentet hentes på serveren, lægges tidspunktet som et timestamp i en cookie. Hvis der er nye beskeder i databasen, som er indsat senere end brugerens seneste timestamp - og som hun derfor ikke har set - hentes disse og formateres som en HTML-streng i JavaScript. Denne HTML-streng indsættes så med JavaScript og innerHTML i hoveddokumentets tabel, når siden loades i iframe'en.
I et helt simpelt HTML-dokument kunne PHP f.eks. skrive to beskeder fra to forskellige brugere sådan:
Se figur 2
Metoden virker, men bl.a. fordi kommende markup-versioner ikke tillader iframes, er den ikke særlig fremtidssikker.
En anden fremgangsmåde består i at indskrive et script-tag med en
query-streng i dokumentet:
Se figur 3
Serveren udskriver så en JavaScript-fil på baggrund af de medsendte variabler. JS-filen indsætter efterfølgende data i HTML-dokumentet, når den ankommer i browseren. Metoden kan dog kun bruges til 'get' forespørgsler, og hver forespørgsel sluger lidt hukommelse, som ikke frigives igen - hvilket ikke er optimalt ved gentagen brug.
Ajax, den nye(ste) teknik
I februar 2005 fandt Jesse James Garrett fra firmaet Adaptive Path på betegnelsen 'Ajax', som dækker over en kombination af allerede kendte teknikker - først og fremmest JavaScript, XMLHttpRequest, DOM, HTML og CSS.
Det var ikke Adaptive Path, der fandt på selve kombinationen af teknikker, men sammentrækningen af 'Asynchronous JavaScript And XMLHttpRequest' til 'Ajax' var deres påhit - ligesom Jesse James Garrett skrev en legendarisk, ofte citeret artikel: 'Ajax: A New Approach to Web Applications' - adaptivepath.com/publications/essays/archives/000385.php
Den væsentligste forskel mellem de asynkrone kommunikationsmetoder ovenfor og med Ajax er XMLHttpRequest-objektet. Det instantieres som ethvert andet JavaScript objekt:
Se figur 4
Ikke overraskende er der lidt forskel på, hvordan det gøres i forskellige browsere. Det kommer jeg ind på i en senere artikel, men princippet er det samme: Et objekt instantieres, hvorefter der kan sendes forespørgsler til serveren og modtages respons fra samme. Så snart objektet er instantieret, er dets properties og metoder ens på tværs af browsere.
Med metoden 'open' åbnes en forbindelse til serveren, samtidig med at request-metoden sættes til 'post' eller 'get'. Udover de to argumenter 'url' og 'method' tager 'open' et tredje argument, som bestemmer, om objektet skal sende og modtage i baggrunden (asynkront). I Ajax sættes dette argument altid til 'true'. Til sidst sendes selve forespørgslen med metoden 'send'.
Objektet kan herefter modtage respons fra serveren i forskellig form. Vælger man at returnere data i form af et XML-dokument, kan dettes DOM tilgås via XMLHttpRequest objektets 'responseXML' property. Vælger man i stedet at sende data retur i form af en streng - f.eks. et JSON-serialiseret objekt - er denne streng at finde i XMLHttpRequest objektets 'responseText' property.
Uanset, hvordan data sendes retur til browseren, indsættes de i HTML-elementer med DOM og JavaScript og indsættes til slut i dokumentets DOM-træ.
I de fleste tutorials om Ajax formateres data i HTML på serveren og indsættes i browseren med 'innerHTML'. I en senere artikel vil jeg vise, hvorfor dette som oftest er en skidt idé - og at DOM-programmering ikke behøver være særlig besværlig, når man bruger DOM'ens fulde potentiale.
Fordele og ulemper
Ved brug af Ajax er det muligt at opnå en glidende programafvikling, der i høj grad ligner den, man kender fra alm. Windows programmer, men med alle webapplikationens fordele - herunder global tilgængelighed.
Det er derfor ikke uden grund, at mange af de store indholdsudbydere er fulgt i Googles fodspor og har implementeret allehånde forskellige Ajax-baserede tjenester. De fleste har nok stiftet bekendtskab med Googles applikationer: GMail, GoogleEarth, GoogleMaps, GoogleSuggest, m.fl. - men også f.eks. Yahoo og danske sites som Krak, Den Blå Avis og Eniro bruger i mere og mere udstrakt grad Ajax i deres tjenester.
Ajax er ikke egnet til søgerelevant indhold!
Det er meget vigtig at lægge mærke til en fælles ting ved disse tjenester: Der er ikke tale om indhold, som skal indekseres af søgemaskiner. Da Ajax er baseret på JavaScript, kan en søgemaskine ikke umiddelbart finde indhold, hentet med Ajax.
Derfor bør man tænke nøje over, hvad man bruger Ajax til. Alle steder, hvor brugeren er logget ind, er det oplagt at bruge Ajax - alle steder, hvor brugeren kan lave beregninger, få vist kort, talopslag, el. lign, kan Ajax med fordel bruges.
Konklusion
AJAX er absolut ikke bare et buzz-fænomen! Brugt med omtanke i den rette kontekst, kan teknikken bidrage med en dramatisk forbedring af brugervenlighed og 'program-feeling'. De tekniske aspekter omkring, hvordan Ajax bruges i praksis, vil blive uddybet i de kommende artikler.
