Over the last three years a tremendous effort has been made in the area of Ajax.  Toolkits, documentation, best practices, tools and tons and tons of applications have been created to make it easier for people to take advantage of Ajax in their own projects.   You can look around the web and read sites like; ajaxian.com and dzone.com to get the latest info and tip to make your site sparkle. The development community has taken charge and created great Ajax libraries like jQuery, Dojo, Prototype, Mootools, GWT.., which remove many of the issues a developer will run into with creating Ajax applications. Tool provides like; Apatana, Eclipse WTP, Firebug, and Nexaweb are continuing to release new versions with upgraded features, which simplify development.  But still it seems something is missing.

In the trenches:

Having worked at Nexaweb for the last five plus years building a Rich Internet Application Platform and tools and using Ajax libraries and tools, I have seen and committed many mistakes when it comes to building Ajax applications.  One of the biggest I have done myself – was not adapting my skills and methodology to JavaScript, instead I trivialized JavaScript and tried to simply port Java and C++. This caused major issues in the performance, stability, and maintainability of the codebase.

I also have worked with others educating them on Ajax performance and usage of Ajax inside of customer engagements and in the general community.  One of the areas I have seen the biggest challenge with still today is simply getting up and running. It is at this point in the project you will make or break it and if not break it, you will cause yourself lots of pain redoing it. The rest of the article is dedicated to what you should know before starting your project.

Now, I will add a disclaimer – “not all rules apply to all projects”.  This is one of the problems and why I have included a very simple histogram to depict what kind of Web application I am talking about.

The Y Axis measures the complexity and richness of the user experience.  As the complexity increases the more demanding the application becomes on the underlying User Agent. At some point your application will need to make the transition from:

•  An HTML to a page-based Ajax Application
•  Page-based Ajax Application to a Single-page Ajax Application
•  Single-page Ajax Application to a Plugin-based Web Application
•  Plugin-based Web Application to a Desktop Application

Each of these different types of applications means different things for your team, skills and the software required.  As I talk about in #3 start with your requirements and let them drive you into the right bucket.  Choosing wrong will mean lots of pain, not the “Saw V” kind of pain, but pain non-the-less.
Some rules of engagement:

Number 1: It’s still a Web Application - An Ajax application is still a Web application and all the best practices and skills necessary for Web applications still apply. However, you will need a few more skills to be successful; Advanced JavaScript, CSS and DOM modifications are all necessary skills for Ajax applications.

So what is different? Well the image above shows what’s different.  In the Web application days of yesteryear all of the logic was on the server-side and you application didn’t worry about the client.  Development was quite “simple”: applications only had state, data and logic in one and that was the server.  In an Ajax Application as your application increases up the complexity curve; you need more state, data and logic on the client, which creates a more client/server like experience.

Distribution of the state, data, and logic or Model/View/Controller to the client increases complexity of your application  not just 2 times but 3 to 4 times. Developers will need to manage both the client and server MVC as well as the synchronization of the state and data.

Ajax or XHR more specifically allow developers to create their own home grown synchronization infrastructure.  Some frameworks have the distribution built-in Nexaweb and Icefaces, DWR, Seam all provide functionality that will make it easier to synchronize state and data as well as call controller logic on either side of the Network. This great simplifies Ajax development.  Even page-based sites like dzone.com and infoq.com use DRW to page data.  The dojo.E project also allow developers to control state from the server-side through a declarative modification language that can be outputted from the server.

Another thing that will simply this complexity is services.  I talk more about this in number 7.

Number 2: Know your application Requirements – Figuring out what your application requirements are seems like a no-brainer but you will need to think about some simple things.  Do I want the back and forward buttons to work?  If so, where do I want them to work in my application? Do I want a certain state to be bookmarkable?  The answers to these questions are probably yes.  It’s on the web someone is going to interact with it as if it was a Web application.  Eventually people will learn the “Back” and “Forward” buttons don’t work in your application, although if people hit the buttons, then they probably should work. Do I want my application to work offline? Do I want a web application feel or a desktop application feel? How long will someone be using the application?

Answering these questions and ones like it will determine where on the user experience curve your application goes.

Number 3: Pick the Right “Toolkit” - In the opening paragraph, I mentioned 5 libraries but could have mentioned a whole bunch more; Backbase, GWT, Echo2, Wicket, Tibco GI… and then all the plugin libraries and even desktop framework.  In the break down of Ajax toolkit options below, I have included only the “Client-side” Ajax libraries. Each library is located where its “center of gravity” is.  This doesn’t mean the library can’t be used outside of this. But just like gravity the farther you get away from the center the less “pull” you’ll get. Want to build a full screen single page Ajax application with just Dojo core and you will need to do a lot of work. The opposite of this is true as well; use a large library for something small and you will need to do a lot drudging through stuff that isn’t needed and spend time shrinking it down.

I didn’t include any server-side frameworks like; Echo2, Wicket or JSF products, these libraries I would place in the Single-Page Ajax application space.

Number 4: *Don’t over do it* – This is an addendum to #3. I see lots of new sites out there that make a full page web application when it isn’t needed.  Creating a simple Ajax application or adding some Ajax widgets might be all that is needed.  Putting your application into the right bucket will give you a much better user experience. I still think the Google Analytics application is one of the Best Ajax application’s that has been built.  It’s a simple page-based, which uses Ajax and Flash in just the right way.  The creators of the application could have went crazy and used GWT and built a single page web application.  Then again why would Google use GWT? Even though I like Analytics there are still Ajax things that bother me; why can’t I use the “back” button when navigating my “Top Content” data with the paging bar?

At Nexaweb we have both an Ajax Client and a Java Client; so I see first hand how people get confused on what richness is needed for an application.  Having both Ajax and Java is great for customers looking to build multiple new applications or modernizing a portfolio of applications; we can cover the complete complexity.  One vendor – multiple client technologies a good choice for enterprises.

Having both Ajax and Java also causes confusion; When/Why should a use Ajax vs. Java? Below is a table of the advantages

====== Ajax ====== Short App Lifecycle/Quick use 3rd Party Components Zero Install mashup / web2.0 / Ajax RIA B2C.com Simple Page-Based Enhance a .com – add widgets, messaging, animation Portal Integration

====== Plugin ====== Long App Lifecycle/Long Use Full screen Large data lots of screens High Performance custom UI lots of realtime data (forExchange) maintenance productivity development tools (debugging) data entry – call enter $ = Key stroke/min

Single-page Ajax applications fall into the Plugin column but the amount of data and complexity of the application will be smaller than their Plugin cousins.

Number 5: Don’t under estimate JavaScript – function validateForm(){} is easy; building an Ajax application is tough. Underestimating or being dismissive about the capabilities of JavaScript will lead to trouble.  Not the kind of trouble that happens when a group of teen agers goes camping in the woods but trouble non-the-less. Attended a Douglas Crockford presentation on JavaScript and you will realized that mastering JavaScript will allow you to truly successful at building a great library or Ajax application.  A good book to read is JavaScript: The Good Parts. Learning JavaScript takes as much time as any other language, the complexity comes in the application of it’s simplicity and dynamic-ness (Not sure that is a word).

Number 6: Performance will be a problem - Don’t believe me – run YSlow! on your application and if you don’t score an F the first time I will give you a free dojo.E T-Shirt.  Send me a screen shot of your application with a B or better and I will send you the T-Shirt.

It is amazing, Web development has been around for 10 years plus and a core software development requirement like performance is still not easy. I have been working at performance and created samples and the jsLex project to make it easier to create highly performant web application. Others have contributed quite a bit to improving performance as well; YSlow, YUICompressor, Dojo Build System, Dean Edwards Packer.  Though even with these tools I still think more can be done.  It would be nice to see a tool like jsLex integrated into Aptana, Visual Studio, Dream Weaver,… No one should ever have an excuse for scoring below a “C” on YSlow! test.  Wouldn’t be nice to bring that “A” home and put it on your refrigerator.

Number 7: Start with services – Don’t get so caught up in the client-side and forget to create your application in a services oriented architecture. I used little s-o-a because it doesn’t need to follow the traditional “SOA” conventions but it does need to be service oriented.  Starting with services and building your application on top of them will mean you have added more flexibility and maintainability into your application right from the beginning.  I haven’t ever built an application that was service driven and been upset with myself in the end.  We are too far along in application development to build monolithic web applications.  Once finished, someone will come up to you and want a piece of the functionality integrated into a different application or into a portal.

Services in today’s application development is less to do about governance (Though it is important) and SOAP than they are about portability of data and widgets across multiple formats and front-ends.  Eventually you will need your data exposed to everyone and your application integrated into Facebook or your corporate portal.

I mentioned in #1 that the Distributed Model View Controller will become easier if you build your application on services.  There are a couple of reasons for this:

1. The service boundary will force you to maintain a clear separation between UI logic and Business logic.  Mixing these on the server as well as the client turns your application into a complete mess.  Not the kind of mess my kids can make with a blender, a cartoon of eggs, milk and flour but a mess non-the-less.
2. You will be able to reuse the work that goes into the services unmodified.

*Note: I will be righting more about services in an upcoming Blog.
Number 8, 9 and 10: Add your own – I could only come up with 7 and a top seven list doesn’t have the same ring as a top ten list – I blame the metric system. So add to the comments other ideas for rules to follow.

Summary:

Hopefully these rules of engagement help you in your Ajax Web Application projects whether you are just getting started or working on kicking off your seven project.  This post was inspired by a recent “customer” conversation I had and hope their project turns out right.

See everyone at AjaxWorld,
Bob (Buffone)