Ajax Design Patterns

pankaj_kumar writes "A number of AJAX libraries and frameworks have emerged to purportedly simplify development of rich Internet Apps. None of them however can substitute a good understanding of what the recurring problems are, the potential solutions and what goes on behind the sleek facade of a browser to power these Apps . Michael Mahemoff, author of Ajax Design Patterns, said this best in his blog which became a popular wiki entry and later, this book." Read the rest of Pankaj's review.

Ajax Design Patterns
author	Michael Mahemoff
pages	635
publisher	O'Reilly
rating	9
reviewer	Pankaj Kumar
ISBN	0-596-10180-5
summary	Creating Web 2.0 Sites with Programming and Usability Patterns

The Ajax Design Patterns book, with its more than 70 design patterns, documented in more than 600 pages with encyclopedic detail, is very effective in presenting the AJAX programming knowledge in a reader friendly format. In the spirit of seminal GoF Design Patterns work, it captures the essence of each of the topics with problem solving approach — first stating the problem in general terms and then presenting the solution, outlining the approach and discussing variations, alternatives, trade-offs and even listing actual uses in real applications. Btw, if you noticed I used the term topics in the previous sentence to refer to its 70+ "knowledge modules" and not patterns, mostly because I wouldn't categorize all of them as patterns. However, this disagreement on terminology doesn't take away anything from their practical usefulness and, for sake of consistency, I would continue calling them "design patterns".

A bit on scope and level of material presented in the book — most of the material is quite advanced and assumes good knowledge of technologies for writing web based applications: HTTP, JavaScript, (X)HTML, CSS, PHP and a bit of W3C DOM. The code fragments, and there are quite a few of those, are in JavaScript (for client side) and PHP (for server side). Most of the prominent AJAX libraries, toolkits and frameworks are also mentioned, often while discussing a particular pattern as a reference of actual use. The appendix lists them all at one place and highlights their main features. Though, the book carefully avoids to recommend any one as 'The AJAX toolkit'.

The book categorises the design patterns as Foundational Technology Patterns (those related to repainting the user interface, browser and web server communication, and event handling), Programming Patterns (those related to programming aspects of either end, browser or the service, of the application), Functionality and Usability Patterns (those related to functional widgets such as slider, data grid, progress indicator etc., page layout, visual effects and so on) and Development Patterns (those related to debugging and testing). Of course, the real value is in the details of each pattern, and not just the high level categorization or overview.

A reader of this review may be interested in knowing why should he or she buy the book when most of the content is freely available at the Ajax Patterns Wiki. Here is my take on this: although most of the content is available on the Wiki, the text in the book has gone through professional editing and is more readable. Also, the description of most of the patterns run into multiple pages, and it becomes hard to read long articles while connected to the Internet (I tend to click on links and wander away). As an additional bonus, the book includes illustrative diagrams, which I found quite helpful, and at times, funny. Most of the patterns included in the book taught me something new, I did end up with a list of favourites after finishing the book in less than a week: XMLHttpRequest Call: One of the most comprehensive treatment of XMLHttpRequest object and its various use patterns, limitations and alternatives. On-Demand JavaScript: How to do lazy loading of JavaScript code to improve responsiveness or get data from a different server. HTTP Streaming: How can a server keep sending data to the browser over an HTTP connection initially established by the browser. Call Tracking, Submission Throttling: How to protect your server from excessive load by very active users without compromising responsiveness. Browser-Side Cache: Ajax doesn't solve the inherent latency problem of the Internet. You still need the good old tricks to improve the user experience. Malleable Content: How to let the user edit some information on a mostly read-only page. One-Second Spotlight, One-Second Mutation: How to communicate change in a portion of the page without being obtrusive. Direct Login: How can you improve the user experience as well as the security of authenticating user using Ajax and JavaScript wizardry. Unique URLs: Going Ajax should not require your users to abandon joys of hyperlinking and the old and tried habits of navigating content by clicking on the familiar back and forward buttons.

So far I have only been talking about things that I liked but there are some things I would consider weak spots. I noticed a few minor typographical issues with certain code fragments, but they are rarely serious. For example the first code fragment on page 96 has uses variable requestTimer to store the return value of setTimeout() and then uses variable requestTimeout as argument to clearTimeout().

A good addition for a future edition could be patterns on AJAX program performance during development, deployment and runtime such as JavaScript compression to improve download times and execution speed and considerations on using multiple third party JavaScript libraries.

Another thing I found a bit annoying at times is presence of a lot of URLs all over the text with hints too brief to allow uninterrupted reading away from the computer. I would have preferred numbered footnotes, either in each page or at the end of each pattern, with URLs and a brief summary of its contents. Usually I read printed books when away from the computer and do not wish to go to the computer and type-in the URLs to just understand what is being said in the text. Although immensely helpful during online viewing, the embedded URLs are a hinderance during offline reading. This is one area where the structure of printed content should be different from the online content.

Overall, I would recommend the Ajax Design Patterns to all those who work or aspire to work on web development projects as an excellent reading and reference resource.

---

You can purchase Ajax Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Whacky AJAX

[dino213b]

More I learn about it, less I want to use it..which is a conundrum because I am developing a project especially meant to use it. It seems that AJAX goes well with entire GUI toolkits so I started with simple transactions and then eventually fell victim to all the shiny features of Dojo - and then got horrified when things started acting like they shouldn't. For example, a nested element causes a to lose the cursor while typing. I don't know how to resolve that -- but -- going back to the drawing board ought to be the way to go.

What are some of your experiences with using AJAX toolkits like Dojo?

Re:Whacky AJAX

[wranlon]

I spent a lot of time between '99 and '02 developing an DHTML toolkit [imnmotion.com] (example [imnmotion.com]). In the summer of 2002 I started working on a rewrite of the widget toolkit, and ultimately created something else - Engine [imnmotion.com]. I wrote an article about the decisions that lead me from the widget-heavy MDI toolkit to service and component orientated Engine toolkit: The Separation of Functionality from Content [imnmotion.com]. Dojo, and the other toolkits that are pretty similar to it, have a lot of neat aspects and very clever widgets. However, there are a lot of corner-cases when dealing with managing events through the DOM and script, and its very easy to miss those situations. I think the Dojo foundation is doing some good work, but, the examples I've seen where Dojo has been implemented has left something to be desired. Also, after refining my approach and using it in high traffic areas (particularly the Web Analytics [imnmotion.com] and window component [imnmotion.com]) I've found it to be much easier to maintain and add/remove as the situation warrants.

Re:"Disagreement on Terminology"

[GOD_ALMIGHTY]

AJAX is a tiny component of the overall distributed application. The distributed application is not written in AJAX. AJAX isn't even a language; JavaScript is. Maybe some people who write AJAX code actually wrote some RPC stuff too, but I'd wager they're just a 13-year-old web monkey. RPC is distributed computing. RMI, CORBA, even XML web services are distributed computing. JavaScript is just glue. Get over it.

In the day and age where I have clients who all now want web apps, but still want all the functionality of a desktop app, you better believe AJAX and this Web 2.0 crap is here to stay. AJAX is also going to stay because the tools are better. I've been avoiding Javascript for years, I can't stand figuring out all the browser quirks, I'd much rather write a Swing app. Google's Web Toolkit changed that. It's a seamless framework for cross-browser applications, I can use CSS to style my UI and Swing like components in a Java IDE to write the actual code. The lack of decent tools is why CORBA didn't take off. Hello World is no less complex in AJAX than CORBA or RMI, it all has to make it across a network and back. It's just that the tools are better, which was probably helped by the lack of complexity in the underlying protocol, but c'est la vie. The web browser is now a rich client. You may believe HTTP is a most horrid protocol for doing RPC or that Javascript is a most horrendous environment for writing anything other than hello world, and I would agree. Like I said, this is all simple CORBA again, but with a universal client app container (the javascript/dom/css capable xml browser) instead of a hand coded top-to-bottom desktop app.

Why wouldn't it make sense to do it this way? We've moved to application containers on the server end to instrument applications with basic infrastructure, why not do it on the desktop too? How is a data structure serialized via a Javascript call to an HTTP request that returns another data structure in an HTTP response any different from RMI, CORBA, MSRPC, XML-RPC or SOAP? Same basic process, so what if Javascript is just glue? By that premise, so is every other language that uses C libraries. Javascript is a scripting language that can be used to draw interactive UI's. The fact that Javascript is not really a great environment to write really interactive UI's doesn't change that. How is GMail any different from early desktop email clients? And I don't even have to actually touch the Javascript if I use existing GWT components, I can write the whole damn thing in Java.

I'd roll my own. If I really needed to write an application that constantly transferred huge amounts back to the client, it'd probably be a clue that a proper desktop client/server app would be a better architecture.

Personally, I'd recommend GWT for Java devs, but to each his own. My question is what if your client requires a web based app? Are you going to tell them you're only going to write that kind of app in a proper desktop environment? CORBA was a damn good architecture too, but how many CORBA apps to I get paid to write? And it's not like our company wouldn't win the work, we've got several people who've rolled their own CORBA orbs. AJAX is here to stay because it fulfills the requirements today. Half the crap on teh Intarweb today would be kicked off if my view of engineering aesthetics were adhered to.

I mean, most AJAX people don't even realize that the server-side input doesn't need to be written in XML. Guess what? if you're receiving so much data back from the server as to need to process huge XML documents, it's just a fast to do a post-back.

You are correct here. That's why I'd recommend a framework, better not to confuse them with your hand rolled hiding of all this. After all, you don't intend on maintaining this thing forever do you? It's also the reason I like CORBA over SOAP, that and SOAP is freaking reinventing every CORBA spec out there, It's not like the CORBA way is any more painful or that the tools couldn't be written just as easi