December, 2006


20
Dec 06

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!

4
Dec 06

Different IEs, same machine

IEBlog posted an article last Thursday on running multiple versions of Internet Explorer for testing purposes. Their suggestion? Virtualization using a downloadable Virtual PC image. Yikes.

Of course, an easier and more realistic way that designers and developers have relied on for over two years is using evolt.org’s standalone versions of IE, based on discoveries made by Joe Maddalone. Even better, download Yousif Al Saif’s self-extracting installer, which lets you conveniently select which versions of Internet Explorer you want to install.

The good news is that now that IE 7 is out in the wild via Windows Update, we can safely begin to ignore IE 5 and 5.5 and focus exclusively on 6 and 7. Frankly, Internet Explorer 8—and with it, the death of 6—can’t come soon enough.

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!