What I learned at the RIA/AJAX BOF @ ETECH

So the RIA BOF at etech was really great. About 45 people showed up, far more than I was expecting, given the short notice. There was a lot of excitement about AJAX at ETech. The term kept on being mentioned by different presenters, and I think that contributed to the number of people who chose to attend the BOF.
etech.gif
The discussion was very free-ranging, with a lot of smart web developers from various companies sharing their tips and tricks. Below are some of the insights that really stuck with me.


1)If you write AJAX code that reacts to the “onHover” of a button, you can get a 1-2 second head start on fetching data. This can end up providing a substantial improvement in a web applications performance, without adding much additional complexity to your app at all!
2)Sending XML doesn’t seem nearly as popular as you would assume from reading all the blogs and documentation on AJAX. The problem seems to be that XML is a)a very verbose format, and b)needs to be parsed on the client afterwards, which can be a big performance hit on clients that have slow processors.
There are a couple of solutions to this problem. One that seems to have promise is using the JSON (JavaScript Object Notation) text format, which is a LOT more terse than XML, and still human readable. Another solution that quite a few participants mentioned was to pre-download HTML (instead of XML) using XMLHttpRequest. While this places a heavier load on the server (basically eliminating any saving of bandwidth arguement for RIAs), it may be the only option for apps that need to be used by clients that have very slow computers.
The ultimate low response time will happen if the app already has the new html ready for the user when they request a new page. One thing I’m going to look at in the coming weeks is pre-generating html in javascript on the client (from XML or JSON data). This should have the same effects on response time (the html will be ready when the user clicks, not just the data) while reducing server load.
3)One of the big (and this may be the deal-breaker) advantages of AJAX over swf-based solutions is that it can be implemented very gradually. An existing web application can add XMLHttpRequest in one or two key places in a week or two to speed up a key area of a web application.
4)You have to be careful with using AJAX to optimize web applications. Even if you increase the speed of an interaction (say from 5 seconds to 3 seconds), the way the browser behaves is different from a simple html reload, and this can confuse users. The only way to know whether this is going to be an issue is to implement the functionality that you want, and then do a usability test. We’ll be looking into this at Uzanto, and I’ll report back any findings on this page.
One of the really interesting things is how many Flash RIA-based startups were present at ETech. Both ODEO and Flickr presented their applications at ETech. ODEO showed off their pod-casting authoring tool. Nobody really talked about the fact that these applications use Flash though: when it works, the implementation technology is invisible!