Ajax Applications and Applications using Ajax
Ajax or otherwise known as Web 2.0 has taken the web development world by storm in the last couple years. Everyone wants their site to be use Ajax or to be Web 2.0. Even if they don’t really gain any benefit from it. But with this, there are two different ways to use Ajax that need to be clarified.
The common applications that have been associated with Ajax, are sites like Google mail or maps. While very useful for a designing a site like that, may have its problems. Spiders cant parse JavaScript, and any indexable content will be unaccessible if you design your site as a one page style application. This is fine for certain applications, like Google mail or maps and Flickr orginizr. Since these sites are purely user oriented.
I think a distinction needs to be drawn between total ajax applications, and applications that use ajax with parts of the interface with certain features. Take a look at Flickr, its organizer is an Ajax application, sort of one page, that uses JavaScript to provide a lot of functionality. The rest of the site is organized in separate pages. More of the tradtional web development approach. But it does on each page, use Ajax based features to provide ease of editing and manipulation of photos.
Development of the first style is pretty simple. Much of back end only provides data in some kind of a transport format (text, JSON or XML). Most of the development then would be focused on the front end. Here the boundaries between the different domains of development are clear.
When I’ve used Ajax, due to the importance of search engines being able to index certain pages, I’ve gone with the Applications using Ajax. In this style of development, many of the development domains are not so clearly seperated. Some of your front end UI is generated with your back-end (PHP in my case), while the rest is generated with the help of JavaScript. So some of the back end code generates JSON for Ajax parts, while other parts generate HTML for the general page layout.
There are also performance issues to consider, while Ajax applications load all the code at once, and only trade data back and forth. Applications using Ajax have to load the toolkit or framework on every page. Looking at some sites, the JavaScript framework itself can be over 100k. Even though its likely cached, it still has to load and process it on every single page load. This is one reason why I tend to use Dojo over other JavaScript frameworks or toolkits. I can load only what a particular page requires. And the bootstrap is very small (25k).
I still have yet to find a development paradigm for Applications using Ajax that works well. Not to say there isn’t one. I just haven’t found one I’m happy with. Right now I have methods to have PHP output in JSON or HTML depending where its used. The business rules behind the output generation is encapsulated in classes, as much as possible. Though the boundaries are sometimes a bit mushy. On the UI side, I develop a framework based on Dojo to auto load on each page. This provides common widgets or UI components that I can make use of on each page. Then on top of that, I build widgets that drive the functions or features for that specific page.
Copyright 2006-2007 Dan Johansson. Except where otherwise noted, content on this site is licensed under a