Does Ajax have a place in the application framework?

“Where’s Ajax?” It’s one of the questions that keeps popping up in reference to Zend Framework. I suppose it’s human nature: most people just don’t get as excited about the fundamentals of the project as I do—the MVC implementation, the Lucene-derived search engine [update: not so much], the caching component. They want flashy stuff. They want Ajax. And they don’t want to work too hard for it.

In the last 10 months, application frameworks have scrambled to be Web 2.0-compatible by creating their own Ajax components. In doing so, they have failed to consider the issue of whether they should, and instead concerned themselves primarily with whether they could. Not surprisingly, this has led to questionable implementations.

To determine whether or not a change should be made in my own applications, I apply a rubric. First, is the change essential? If so, the choice is clear; do it. If not, I continue to ask questions. In which ways would the change be beneficial? How would it be harmful? And so on.

Naturally, this same set of questions is applicable to the topic at hand, so let’s examine each in turn.

First, is it essential? Application frameworks are designed for the server-side. What interaction does Ajax have with the server, besides requesting a given URL via GET, POST, or some other method, and interpreting the result? None; this process is the same as a standard Web request. Ajax, therefore, does nothing new or spectacular from the point of view of the server, so it’s not fulfilling a fundamental need.

Is it beneficial? Most Ajax components wrap JavaScript libraries like Script.aculo.us or Dojo, even to the point of using identical method names. For those with a basic understanding of JavaScript, how much time is saved here over using those libraries directly, really? For those without that understanding, is it wise to incorporate technology into your application without knowing how it works, at least broadly? Better to spend a day learning JavaScript and the principles behind XMLHttpRequest and then choose a JavaScript library that best matches your needs and programming style. Why write more lines in Java with Wicket when you could just write JavaScript directly?

As far as I can tell, most of these components exist simply so that developers can stay cozy and warm within the cocoon of their favorite language, without having to venture out into another one. This is a particularly common attitude among Java developers, as Google Web Toolkit illustrates. Although it has plenty of stated benefits (some of them of questionable validity), let’s be frank—the real reason to use it is to never have to write a line of JavaScript. Is JavaScript so bad that it’s better to have to compile it from some other language, especially when excellent debuggers like Firebug exist?

Is it harmful? One of the most basic tenets of modern web development is the separation of presentation and logic, but Ajax components often ignore this concept. Although some implementations involve the creation of entire forms from within the controller, let’s assume a more intelligent design, as a view helper.

Even with a view helper implementation, you’re suddenly presented with a problem: unless the code is prepared in some way prior to run-time (similar to a “compile” step), you’re now most likely mixing JavaScript event handling with your HTML. Some people don’t even realize that this is a problem. However, just as server-side logic should be separated from the view (as with a multitier architecture) and style should be separated from content (as with CSS), behavior has no place within the presentation. That is to say, JavaScript belongs in a separate, included file. It’s called “unobtrusive JavaScript“.

As typically implemented, Ajax components also have the practical effect of preventing those without JavaScript from using the application at all. That includes visitors using screen reading software, most visitors using some sort of mobile browser, and many corporate users straining under IT paranoia. Altogether, these can account for up to 5% of all visitors to a public website. If frameworks are generating inaccessible code, then it is just as much their fault as the fault of the developer using the tool.

Conclusion

It seems clear to me that Ajax components add no real value if the code is not prepared prior to run-time, and little value if it is. Instead of creating Ajax components, framework developers should let JavaScript library developers handle Ajax simplification and focus on other matters. JavaScript is good and it has its place, but not within the application framework.

Like this post? You might also like Coalmine, my centralized error tracking service for your apps. Coalmine captures errors and all kinds of helpful debugging information, notifies you, and makes it all searchable. Check it out!

Tags: , , ,

4 comments

  1. When people say “where’s Ajax?” when looking at a framework, I’d guess that the problem they actually have revolves around how to fit the server-side Ajax responses to incoming XMLHttpRequests into their framework-based application. Especially at the view level which is probably build around the construction of complete (x)html pages rather than responding with fragments of Json or XML.

    Regards,

    Rob…

  2. I would agree with Rob in saying that the answer to the question “where’s Ajax?” does not necessarily mean that people want the anser to be “right there, in the AJAX component.”
    But leaving the entire subject out of the book suggests that there is no “support” for AJAX (even though you already stated that there is no such thing because AJAX does nothing new from point of view of the server).

    Maybe an addition to the manual with suggestions for some of the stronger JavaScript libraries and perhaps a real-world example would be enough of an answer for most.

    In any case, your argument for not including a sloppy component for the sake of having it is absolutely valid.

    Regards,

    Ramon

  3. Although I agree, there are people looking for “Zend_Ajax”—including Zend, for a time:

    ZAjax (proposal)
    Proposed by IBM and approved. I’m sure a lot of work went into this, but the use cases are truly terrifying, and it needlessly duplicates a lot of functionality already existing in much more complete JavaScript libraries like Prototype. ZAjax.js is even still in the incubator under Zend_Form, even though that component’s dead and hasn’t been worked on since the initial import.

    Zend_SimpleAjax (proposal and comments; rejected in favor of ZAjax)

    Zend_Ajax (proposal)

  4. Great article, Matt.

    I think that asking “Where is Ajax” in a server-side framework, looking for a view component to handle Ajax responses and JSON, is a misunderstanding of the MVC concept. Of course, this is not science, but then again when it comes to buzzwords like Ajax / MVC / Web 2.0, nothing is science…

    The way I like to think of it is that when you use Ajax, the server-side view components kind of become your client-side “Model” – that is the part that’s responsible for fetching data. Server side “View” components (like Zend_View) should render nothing when used through Ajax – only kind of encode the data and pass it to the next stage, which is the client side “Controller”. In the rare cases I used Ajax, I actually did the encoding (to JSON or XML) in the server-side controller, and just passed it to a blank, empty View class that just sent the encoded data to the client side.

    You kind of end up with a double MVC layer – one on the server, and one on the client – and the server’s view should do nothing when it comes to Ajax IMHO.

    Oh boy.. that came up much more messed up that I planned to.. ;)

Leave a comment