Client- and Server-leaning Approaches to Ajax
Writing javascript seems to be a scary prospect for a lot of folk. This is understandable given the tangled mess of code that can easily accumulate if you treat it as a toy language, and slap the code together in a hurry without thinking of an overall design.
Tor Norbye of Sun’s Studio Creator team blogged recently about the Ajax features in an upcoming set of JSF components that play nicely with Studio creator. Tellingly, he had this to say:
This is an ideal domain for a JSF component. The JSF component can encapsulate all the hard work in its renderer, meaning that your JSP files contain no JavaScript code whatsoever. You get the benefits of AJAX without its usual high development cost.
which I can imagine struck a chord with many people. Having to write a full widget set from scratch is a lot more trouble than getting a pre-written framework to do it for you.
JSF, and similar component-based server side models like Tapestry and .NET Forms, provide such a framework. On the other hand, so does a pure javascript widget set like Qooxdoo or f(m) - to pick a couple of names from the ever-filling hat of ajax frameworks. A suitably mature javascript toolkit could expose API’s every bit as simple as those of a JSF component suite. The guys behind Tibet have even thrown in a drag-n-drop IDE written in javascript, without being tied to a single back-end technology.
So there are two quite different approaches to doing Ajax. On the one hand, the JSF way - let’s call it server-leaning to avoid picking on a single technology -controls everything on the server, and code-generates all the javascript for you. The other way - let’s call it client-leaning - consists of a client composed of static javascript files (say 95% library, 5% app-specific), that talks to the server in standardised dialects like XML, JSON or SOAP. In a client-leaning architecture, the server has a lot less to do. It is basically generating data-feeds for a largely independent app.
There are many server languages/frameworks out there (and four successful ones at present: Java, PHP, .Net and Ruby). There’s only one client-side language - Javascript. And some developers feel uneasy about javascript. It is a powerful (and, in places, weird) language, and a java dev needs some orientation in order to pick it up. Ruby or Python are probably the closest in overall ‘feel’, in my entirely subjective opinion. There’s a fuller discussion on java and javascript in the forthcoming book by myself and Eric, (courtesy of the shameless plug department).
So anyway, server-leaning wins on the developer-discomfort-with-strange-languages score.
I lean towards the client-leaning architecture myself, because I am comfortable with javascript after several years of exposure, and because I like the simplicity of writing an app in the language that it will be run in, rather than code-generating it from a data model in a foreign language. So client-leaning gets a point for elegance.
What are the other differentiators here? A few contenders:
- Performance and scalability: moving the domain model over to the client gives access to a veritable grid of underused CPUs, and takes a load off the server. Sure javascript is slower than java and sever-side pals, but the server-leaning architecture needs to generate javascript too
- Freedom: simplifying the server tier makes it easy to move from one server technology to another. If your ajax client speaks a standardised dialect, such as RSS, for example, then several suitable back-end servers will already exist. Could the big vendors be keen on a server-leaning solution because it locks the customer in to their technology? Microsoft’s anticipated ‘Atlas’ will run on all standards-compliant browsers, but only on MS server frameworks. Ditto for JSF and the java stack. I’m not suggesting a conspiracy here, but I’m willing to bet that this is a contributing factor to the preference for server-leaning solutions.
- Loose coupling: between client and server makes testing easier.
I’m sure that I’ve missed a few other differentiators between the two approaches. I’d be interested to know where your preferences lie along this line, dear readers. What are your experiences of using either approach?