One of the questions I hear often is which Ajax framework to choose for building ajax-enabled apps. One way to answer this question is by comparing and contrasting – see which framework offers what kind of features, and compare those among various frameworks. That is an easy approach. But I’m beginning to realize that this is not necessarily the best approach towards selecting a framework. I think a more important criterion is how well a given framework can deal with heterogeneity.
Yes, heterogeneity. The same old problem that led to the realization of loose-coupling of services in the form of SOA.
The web as exists today is not homogeneous. There are sites and web apps built using a variety of web programming frameworks ranging from CGI/perl to PHP to JSP, ASP, JSF etc. In fact, there is almost no enterprise that has a homogeneous technology used to build all its web apps. It just is not possible for such homogeneity to exist in an enterprise. Even if all the apps are built using a suite from a given vendor or technology (like everything built on Microsoft’s suite or JEE from some vendor or something else), there are going to differences between the versions and products used, leading to a tech-soup of heterogeneity at the UI layer.
For someone trying to simplify the enterprise, homogeneity is great, and heterogeneity hurts. But years of watching the evolution of technologies in waves should make one realize that heterogeneity is here to stay. At the technical level, I find it more interesting to think in terms of heterogeneity – it is a much more challenging problem to integrate heterogeneous services than homogeneous services.
This is all fine at the service-level, but why care about the UI level? Increasingly, the browser is becoming a service client, and is able to fetch data/UI over HTTP from various services. Most modern apps are now being built this way. Yahoo Mail is one great example, but there are several others following this pattern. I like this pattern since it shifts the UI composition from the server to the browser. Instead of putting UI snippets into a page on the server side, this pattern is based on the client fetching data/UI and continually updating the view as the user is interacting with the site. It also imposes some kind of formalization of interactions between the client and the server-side, and this is a key characteristic of ajax applications. You will see this kind of formalization in the REST/http web services offered by Amazon, Google, Yahoo, Flickr and others.
One of the requirements I place on Ajax frameworks is, therefore, an ability to work with any service providing data or UI on the server side. What does it mean for the Ajax framework? The framework should not impose restrictions on the kind of technology that I can use on the server side. There is another way to look at this. In SOA, yo don’t want the service telling the client the technology it must use to make use of the service. In a world where the browser is a universal data/UI client, the same principle applies to the technology used to build the client. It should be agnostic of the choices made on the server side. The only thing that should matter is the set of operations over HTTP to fetch/update UI and data.
This is one reason I prefer pure-client side Ajax frameworks, like Dojo, over other frameworks that have server-side components. A pure client-side framework would let me write the client-side without depending on the decisions made on the server-side. For instance, most JSF-based Ajax frameworks require you to think in terms of JSF both on the server side and the browser-side. I’m yet to be convinced that this is a good approach. What concerns me is that, the JSF-frameworks that I have experienced with tend to generate the client side based on the decisions made at the JSF component level on the server side. This makes sense in a homogeneous world. But once you attempt to write a new app (a la mashup) integrating the JSF generated UI with something else, it will be easy to realize that the integration gets hard because most of these frameworks don’t tend to formalize the interactions (i.e. the protocol) between the client-side and server-side components leaving a fair-bit coupling between the client (the browser) and the server side code.
So, a good ajax framework is one that lets me maintain decoupling between the client-side code (HTML, JavaScript, DOM, events etc.) and the server-side code. A given framework may offer great help in blending Ajax with the web programming model, but if it does not address heterogeneity, it is not good enough in the long run.
(Cross posted at http://dev2dev.bea.com/blog/sallamar/archive/2007/06/ajax_frameworks.html)
{ 1 comment… read it below or add one }
Hey Subbu… Nice post. I even think the same way. I want my client code to be independent of the server code. When I first read GWT’s RPC approach, I thought the same way. But seeing that GWT can also work with normal Ajax calls without using RPC I was relieved. I didn’t want to miss out the advantage of using GWT and coding client UI in Java just because of this reason.
[Reply]