Commentaar op AJAX (en web applicaties)

Saturday 26 November 2005, 13:56:00 | web dev

Ik heb daarnet een artikeltje geblogd dat ik wel eens wat wil experimenteren met AJAX, maar het is ook goed om eens stil te staan bij wat het nou eigenlijk is. En hoe abominabel het eigenlijk is gesteld met veel "web applicaties". :-S

Sommige mensen beweren (terecht of onterecht, dat moet je zelf maar uitmaken) dat web applicaties in een web browser de ontwikkeling op user interface gebied weer tien jaar hebben teruggedraaid. In sommige gevallen ben ik het hier zeker mee eens! Hoewel er een markt is voor web applicaties, gebeurt het helaas ook maar al te vaak dat een systeem dat zich eigenlijk helemaal niet leent voor implementatie als web applicatie, toch op deze wijze wordt opgezet. En de gebruikers daarvan moeten dan werken met een traag, simpel, gebruiksONvriendelijk, soms zelfs irritant systeem. Terwijl een 'normale' applicatie (dat wil zeggen, een echte desktop applicatie bijvoorbeeld gemaakt in Java, VB, Delphi of C#) veel beter zou zijn geweest omdat het daar wel mogelijk is om geavanceerde user interface mogelijkheden toe te passen (drag-drop die goed werkt, snelle verwerking, meerdere windows, etc etc)

Verder is er ook nog commentaar te leveren op de hele AJAX hype. Iemand op slashdot:

Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.

Een beetje overdreven, maar lees het nog een keertje door en denk er eens over na. Het is wel een beetje waar wat hij zegt of niet soms? %-|

People have replied:

ingo

2006-01-18 09:52:00

My dutch is pretty basic, so I'll reply to the english quote.

Firstly, state: Associating application state with connection state is dubious, at best. In any case, in HTTP state is not thrown away completely but rather kept on the client (in the transmitted document). In protocols that share it between client and server, the server has a much harder task. Look at how much concurrent users an IMAP server can tolerate (~100 - max 1000) and how much concurrent users a web-server can (at least ~10.000s). A side-benefit is that keeping state on the client encourages open interfaces, which are more extensible.

Secondly, screen refresh: True, one page at a time, not as good. However, look at the design quality of that one page and at the design quality of GUI applications ;-)

Thiel

2006-05-26 11:49:00

Geachte heer de Jong,

Ik kan mij geheel vinden in uw opmerking over Ajax. Zou het met Feijenoord beter gaan?

Groet,

Thiel

Irmen de Jong

2006-05-26 19:46:00

Hahahaha ^_^

Sja ik kan het ook niet helpen dat ze een voetbalclub hebben bedacht die hetzelfde heet als een Javascript/XML communicatie principe :-P

Misschien moet ik inderdaad zelf maar iets in elkaar klussen en dat Feijenoord noemen. <script src="feijenoord.js"> .... wel grappig eigenlijk !

Bedankt voor het mailtje !