I think there’s going to be two kinds of AJAX application, one I’ll dub “HTML++” and the other being the Client / SOA Bill mentions. To describe them roughly…
HTML++
AJAX is used to enhance existing HTML forms / user interaction but the fundamental paradigm is still the same as “normal” web applications. Some key smells of this style;
- Page reloads still happen frequently
- It’s possible (if you make the effort) to degrade gracefully to non-supporting browsers / browsers with JS turned off.
- Session state still resides on the server.
In practice this is what everyone’s doing right now, with varying degrees of success. For many I think the effort and cost to “go HTML++” will far outweigh the benefit. Practically think this is best done server-side with tools like HTML_AJAX that do the “thinking” for you (side note: while giving a talk at this year’s AJAX@localhost PHP conference, mentioned JPSpan is effectively dead – HTML_AJAX is, to some extent, it’s successor – it’s a bit like PEAR::SOAP and NuSOAP).
Meanwhile an interesting “in between” example, which I think highlights the divide, is the script.aculo.us shopping cart. Every time you place an item in the cart, it tells the server about it then retrieves a fresh list of cart contents and updates the client side. In other words the server is the judge of what’s in your cart. It’s interesting because you might argue that the cart could stay purely client-side, only sending anything to the server when you decide to head to the “checkout”. In practice though, it’s likely the cart would be used on sites where it’s expected to work across multiple “pages” (or tabs), which share a single server-side session.
Client / SOA
As Bill called it Client / SOA will use the same. SOA may not yet be concept which readily communicates ideas. My angle of understanding this begins with asking AJAX: what’s a session?. An alternative angle comes from Cédric Savarese over at Form Assembly in Ajax: It’s not all about XMLHTTPRequest (and part 2), a train of thought which leads to what he’s done with the freja framework.
Some of the key smells with Client / SOA;
- Page reloads are rare, if at all. The application tends to run in a single browser window.
- It’s practically impossible to degrade gracefully, without maintaining seperate code bases.
- Session state is largely handled by the client.
- Javascript and the browser are acting as a runtime in the same sense as the Java or .NET runtime.
- It’s going to require specialist developers
Really it’s probably wrong to use the word AJAX here at all. To enable this style of application you need a lot of Javascript glue and what we call AJAX would likely be so deeply buried that it’s barely reflected in the APIs you call as an application developer.
As far as I know, Tibet is the only Open Source project today which would be capable of making this happen and, right now, there’s no code available – you need to wait for the next release (due soon). Meanwhile, via Google, you’ll find people raving about Tibet all the way back to April 2001.
What kind of applications will be built this way remains to be seen. Superficially these will be the equivalent to today’s desktop applications but think the winners here won’t be those simply trying to re-invent what already works. For example the race is already on to build web based Office Suites, but I think that’s largely a fools game. Thinking in terms of MS Word, specifically, if you’ve ever seen what companies typically do with Word templates and consider why MS developed InfoPath, you realise that word processors as a “unit of application” is no longer interesting. Something more like “living documents”, relevant to a specific type of information a group of humans is trying to organise, and incorporating things like collaboration, versioning and workflow is far more interesting.
Also this kind of application could, potentially, be eclipsed by another technology, such as stuff Microsoft are packing into Vista or something XUL-based (perhaps just Firefox extensions). Think alot depends on what happens in the next 12 months.
Anyway – thats just my thinking, bordering dangerously on marketecture, but in the interest of trying to nail down the relevance of AJAX.
Harry FuecksHarry Fuecks is the Engineering Project Lead at Tamedia and formerly the Head of Engineering at Squirro. He is a data-driven facilitator, leader, coach and specializes in line management, hiring software engineers, analytics, mobile, and marketing. Harry also enjoys writing and you can read his articles on SitePoint and Medium.
