Ajax anti-patterns
Microsoft recently rolled out live.com, a beta Ajax home page, to mixed reviews. The interesting part to me in all this are the lessons that can be learned, not just for improving live.com, but for all Ajax enabled applications. In a candid article, team member Scott Isaacs dissects the problems they have identified so far. I'll summarize the basic points here. Consider these Ajax anti-patterns, though you'll find they are equally applicable to Java, .NET, and other runtime environments.
1. Chatty communication. Long considered an anti-pattern for any kind of distributed applications, chatty communication rears its ugly head once again in this new medium. The solution is to reduce the number of connections, cache more, and batch multiple requests. Another idea is to split resources across servers because some browsers are limited to 2 active connections per domain.
2. Too much XML parsing. XML is great: it's self-describing, human readable, and well supported. But the XML libraries supplied by today's browsers are not terribly swift. Scott reports that on his machine it took 400ms to parse 150K of XML, which is way too much considering you want to get a response back to the user in 100ms or so. The solution is to reduce the amount of data transferred, or consider an alternative format such as JSON.
3. Loading everything before displaying something. The most straightforward way to design your application is to load all your code, get everything initialized and happy, and then start thinking about drawing to the screen. If you can't get all that done quickly (100-500ms) then the user will perceive the application as being very slow. The solution is to load an initialize only what you absolutely need to put something on the screen and then load the rest only as needed. Scott calls this "staging" but I would call it "lazy loading".
4. Rendering on the server. For split client/server applications like those you build with Ajax technologies, there's a constant tension between how much you put on the client and how much on the server. The server is more trusted, and more controlled, and you have a choice of languages and environments to use there. The client is fragile, exposed, but closer to the user. The whole point of Ajax is to move some things closer to the client to get a more interactive experience. Although the first time a web page loads, a server-generated page may be faster, overall you're better off the more you can move to the client, keeping in mind the other anti-patterns listed above.
I have one more to add that Scott didn't mention, but it's clear he's thinking along these lines:
5. Over thinking the design. In traditional development you have to spend a lot of time up front on your requirements an architecture because a) releases are few and far between, and b) it's very hard to code updates and get them out in the field. "Web 2.0" means many things to many people, but one consistent thread is that of agile development. Frequent releases, and easy updates are the rule, not the exception, so you should take advantage of that from day one.