Lessons learned from building complex ajax pages

I’ve worked in a couple of very complex ajax web pages, so I would like to share with you my experiences on what helped me to do them right, and algo what I should have done to make them better and easier to mantain.

Specify supported browser’s and versions

This is a rule before starting any web project. If the project doesn’t specify this I can assure you that the release date won’t be met because:

  • QA effort are incremented exponentially
  • Code will have constant modifications just so that a specific browser works correctly. This is very dangerous, since the code becomes very cluttered, hard to mantain and also loses focus on business rules and value
  • If Internet Explorer 6 support is required, be sure to communicate your sponsors of an extension in the release plan. A very long extension
  • If you can, promote the use of the Google Chrome Browser to your sponsors. It is has by far the fastest javascript implementation, wastes minimum CPU resources and has great developer tools.

Use Javascript libraries

  • These ones are a must. You must have a full fledged library (dojo, jquery or yui are the most widely used).
  • Spend some time learning the library’s utility methods, they will save you tons of time
    • Dojo, for example, has a great tool which is dojo.query, and also has very powerful and highly configurable GUI components and effects
    • jQuery has a very easy to use implementation of ajax, tons of plug ins and is very memory efficient
  • Don’t mix up different libraries, since they will probably clash and the resulting bugs can be quite hard to detect.
    • Besides, using only one library allows an easier maintenance of the code, and the learning curve is shortened
  • Never use standard javascript. Always prefer the library’s utility methods
    • When starting the project, be sure to constantly perform code reviews to ensure that the team is using the library. Sometimes the team underates the importance of this and uses common javascript to perform operations. In the long run this is counter productive because can cause browser compatibility issues and breaks standards in the code.

Become a CSS expert

Unless you don’t care that your code becomes messy, and lacking a common, standardized user interface, become an expert in CSS and make sure that your web pages use it as much as possible.

Define user notification standards ASAP

Loading messages, error messages, notification messages and all that must be defined up front, ending up with a standard template that each page must use. If this step is delayed, each page will be messy and hard to mantain. One page will use the typical and ugly javascript alerts while other will use a fancier div alert.

Also, define how are you going to prevent multi submit’s, either by blocking all buttons, or having the “loading…” message put a gray transparent div over the form to prevent clics.

Avoid GUI tree structures

Many javascript libraries support data trees. Unless the data amount is low and require basic user interaction, avoid them by all means. I worked on an interface that consisted of only a tree that required to load over a 100 nodes, where each of those nodes could load up to 2000+ nodes. It was a nightmare and I ended up having to modify the tree component to add ajax support (because the browser collapsed by transforming all the data into nodes with the pretty images and all that) and after that, I realized that some nodes required that I controlled javascript so that the sub nodes were loaded in intervals in order to prevent the browser from collapsing.

Don’t blindly trust javascript performance

If your web page handles a lot of information, figure out how to balance user experience with resource usage; to be constantly freeing up javascript memory without making constant calls to the server to save it. It can be tempting to think that you can hold all data in javascript variables until you do a submit, but you have to be very careful not to miss a scenario that requires huge volumes of data, which will for sure slow down or even crash your browser or server (think of the case where all the data in your javascript has to be transformed from json to your server side objects, this operation is very resource consuming and can easily consume your server resources)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s