Ruim een jaar geleden (2005) werd de term geïntroduceerd en niemand kan het zijn ontgaan: AJAX (Asynchronous Javascript And XML). Het AJAX concept beschrijft hoe je een website dynamisch kunt maken door op een bepaalde manier content van de server te halen en deze in de huidige pagina te plaatsen. Hierbij is het dus niet nodig een nieuwe pagina op te halen. Er wordt nog steeds over AJAX gesproken waarbij nog steeds dezelfde voorbeelden, zoals Google Suggest, worden gebruikt. Dit impliceert dat AJAX erg onbegrijpelijk is, of dat het toch niet zo makkelijk is in te zetten als velen beweren.

Op het internet zijn veel tutorials te vinden die uitleggen hoe AJAX werkt. Met wat kopieer- en plakwerk is een eigen demo in een paar minuten in elkaar te zetten. Onbegrijpelijk? Niet echt, zolang de onderliggende technologieën van XHTML, CSS, Javascript en Document Object Model maar bekend zijn. De technologieën op zich zijn volwassen en stabiel en staan de keuze voor AJAX niet in de weg. De enige keuze die gemaakt moet worden is of AJAX passend is voor een applicatie.

(Dit artikel is eerder verschenen in de september editie van ‘IT Monitor’, een uitgave van de Studievereniging Bestuurlijke Informatiekunde te Tilburg.)

De keuze van de klant

Klanten vragen tegenwoordig regelmatig om wat ‘AJAX-dingetjes’. Vaak wordt bedoeld dat er grafische effecten toegevoegd moeten worden (bijvoorbeeld teksten die met een muisklik verschijnen en verdwijnen). Dit kan prima gerealiseerd worden met Javascript, een van de centrale componenten van AJAX. Lange tijd werd Javascript echter gemeden op publieke websites omdat het misschien wel gevaarlijke dingen kon doen met de computer van de eindgebruiker.

Verder kan er met Javascript niet meer zo makkelijk voldaan worden aan de W3C usability guidelines en de ‘drempels weg’ richtlijnen. Deze voorschriften zijn erop gericht dat visueel gehandicapten de website ook kunnen gebruiken. Met AJAX is dit vrijwel onmogelijk omdat het de pagina verandert nadat de pagina geladen is. De meeste hulpmiddelen van visueel gehandicapten kunnen hier niet goed mee over weg. De drempels weg richtlijnen raden daarom ook af om Javascript te gebruiken.

Echter, als een klant aangeeft dat AJAX gebruikt mag worden, heeft de eigenaar impliciet toestemming gegeven om Javascript te gebruiken. Een wereld van mogelijkheden gaat open…

De keuze van de ontwikkelaar

Ondanks dat Javascript er al was toen internet door de massa ontdekt werd, hebben webapplicatie ontwikkelaars lange tijd gekozen om de Javascript taal links laten liggen. Hiervoor zijn een aantal redenen.

De eerste reden is dat Javascript in het begin niet gestandaardiseerd was. Het Javascript van de Netscape browser (die als eerste Javascript introduceerde) was anders dan het vergelijkbare taaltje dat Microsoft in hun browser stopte. Intussen is Javascript volwassen geworden. Er is overeenstemming gekomen over welke features de taal minimaal moet hebben en de syntax is hetzelfde geworden. Er zijn echter nog steeds onhandige verschillen. Vroeger leidde dit tot uitgebreide if-else constructies. Maar gelukkig zijn er intussen genoeg open source Javascript libraries die de verschillen kunnen afschermen voor de ontwikkelaar.

Een andere reden is dat er traditioneel weinig tools zijn ter ondersteuning waren voor de ontwikkeling van Javascript. In de laatste jaren is (door de belofte van AJAX) deze achterstand echter ook weggewerkt.

Tot slot zijn niet alle ontwikkelaars goed met Javascript bekend. Een web ontwikkelaar gebruikt een taal zoals Java, Ruby, Php of Asp op de server. Dit is de primaire taal waarin de applicatie wordt geschreven. Javascript is de tweede taal waarin de ontwikkelaar niet altijd een expert hoeft te zijn. Als het wat lastig wordt in de browser dan valt de ontwikkelaar al snel terug naar zijn primaire taal en zal de interactie dus via de server lopen. Javascript heeft in de loop van de tijd laten zien dat het in staat is om zich aan te passen aan de ontwikkelaar. Een aantal libraries zijn ontwikkeld vanuit de syntax van de primaire taal. Dojo past bijvoorbeeld goed bij Java en Prototype bij Ruby. Doordat de syntax hetzelfde lijkt, weet de ontwikkelaar zijn weg beter te vinden. De libraries verbergen ook de verschillen van de browser waardoor de ontwikkelaar maar één functie-set hoeft te kennen.

De keuze van de architect

Uit het bovenstaande is te concluderen dat kiezen voor AJAX geen probleem meer is voor de ontwikkelaar. De keuze voor AJAX is niet meer techniek gedreven. Het is tegenwoordig een architectuur vraagstuk geworden. Een architect kiest de technologieën en hoe ze gebruikt gaan worden. Als de architect kiest voor AJAX moet hij nog bepalen hoe centraal het komt te staan in de applicatie. AJAX kan alleen voor het invullen van formulieren gebruikt worden (Google Suggest) of voor het verversen van hele vlakken binnen de pagina (Google Mail en Google Maps).

Om te bepalen of AJAX gewenst is moet er eerst bepaald worden wat voor soort interactie de website moet hebben. Veel websites, die publiek te benaderen zijn, zijn van informatieve aard. Deze zijn typisch van bedrijven die aanwezig willen zijn op het internet zodat mensen hun kunnen vinden. Voor dit soort websites is een content management systeem als backend genoeg. Nieuwssites vallen ook onder deze categorie. De traditionele manier van hyperlinks volgen is zeer geschikt voor deze sites. Gebruikers kunnen de pagina’s bookmarken en zoekmachines kunnen een directe link opnemen in de zoekindex.
Wordt toch besloten deze categorie van sites om te zetten naar AJAX (zoals de Google Mail variant), dan moeten voor alle traditionele features alternatieven komen. Hier zijn vaak wel oplossingen voor, maar je moet dan wel goed de voordelen van AJAX opwegen tegen het extra werk.

Voor een online shop is het zeer belangrijk dat alle producten in de catalogus goed vindbaar zijn in een zoekmachine. Mensen zoeken niet naar een online shop, maar naar een online shop die hun product verkopen. Directe hyperlinks naar producten is een vereiste. Is de klant eenmaal op de website aangekomen, dan is een online shop is in feite één grote formulier-invul en keuze interactie. AJAX is zeer geschikt om deze interactie te verbeteren. Bezoekers hoeven na het kiezen van een optie niet meer te wachten op een nieuwe pagina en ze krijgen direct feedback als er iets niet goed is. De bezoeker wordt daardoor sneller door de website naar de bestel knop geleid en daar gaat het natuurlijk allemaal om.

Een grote groep applicaties waar AJAX frameworks zich op richten zijn de data-entry applicaties. Centraal in deze applicaties is het invoeren van formulieren en opzoeken van gegevens. Voorbeelden hiervan zijn voorraadbeheer-, klantenbeheer- en boekhoudapplicaties. Deze applicaties komt nu ook vaak beschikbaar als webapplicatie via een intranet. Deze ontwikkeling is mogelijk gemaakt doordat AJAX dezelfde gebruikers interactie kan bieden als de traditionele standalone client applicaties.
Voor dit soort applicatie moet de architect zich echter bedenken dat web ontwikkelaars moeten wennen aan het feit dat niet alles aan de serverkant gedaan hoeft te worden. Traditioneel paginagebaseerde webapplicaties onthouden alle gegevens aan de serverkant. In AJAX-gebaseerde webapplicaties kan veel aan de browserkant onthouden worden en hoeft alleen de minimale set aan gegevens gesynchroniseerd te worden met de server. Dit is de normale gang van zaken in standalone client applicaties. Een ontwikkelaar die niet anders doet dan standalone applicaties maken zal juist moeten wennen aan de web technologieën.

Alhoewel een data-entry webapplicatie gebaseerd op AJAX vrijwel alles kan wat een standalone client applicatie kan, blijven er altijd wat features over die door een browser niet zijn toegestaan. Een web applicatie wordt namelijk uitgevoerd in een gecontroleerde omgeving in de browser waar lokale bronnen niet mogen worden benaderen. Hierdoor kan Javascript bijvoorbeeld niet schrijven of lezen uit een bestand. Integratie met andere applicaties is ook niet of nauwelijks mogelijk. Indien deze features wel vereist zijn is Java webstart is een goed alternatief.

Conclusie

In de web-wereld zijn in de afgelopen jaren twee belangrijke best practices toegepast. Ten eerste is (Javascript) code gegeneraliseerd naar libraries en ten tweede worden technologieën gebruikt voor de dingen waar ze goed in zijn: XHTML voor het structureren van data, CSS voor het opmaken van die structuur en Javascript voor het toevoegen van dynamiek. Een logisch gevolg in het jaar 2005 was de stap naar een betere definitie van hoe deze technologieën samen ingezet kunnen worden. AJAX is een afkorting voor een van deze definities.

Om een applicatie te realiseren moet een architect bepalen wat de wensen en keuzes zijn van de klant en de ontwikkelaar. Samen met de eisen van de applicatie kan gekozen worden voor AJAX. AJAX moet dan wel voor de applicatie toegevoegde waarde hebben.