In the Ruby on Rails framework, Ajax is easy. Pathetically easy. Combine one part what you have already, one part ‘_remote’, and one part ‘:update’ (that is, those are the code pieces you need to change), and presto — you have one slick application, capable of performing actions without a single page refresh. Add into the mix a bunch of script.aculo.us helpers, which allow you to easily (after a bit of requisite trial and error that goes with doing anything new) offer up some fun flashy bits, and … well, long story short, I found myself lost in too much power all too quickly. Preposterous though it may seem, there are times, the experts tell me, when I shouldn’t use Ajax for all pages and all actions and all data. (Hmm … haven’t all Web developers been down this road before?)
The reason I thought of Rails at all in the beginning was because I was tasked with building very user-friendly Web forms. I’d read that Rails had great Ajax support (and wow, does it!), which is great for forms. The prevailing wisdom is that Ajax, which can be used to refresh a small part of a page instead of the whole thing, can and should be used for actions — which is what forms are all about — and developers should avoid using it when they want their data exposed to search engines such as Google (because the search bots will only be able to see an Ajax call and not the data that will be called when someone loads a page) or when there are things that will need to be bookmarked or linked to in some way (because you can’t link to anything exposed by an Ajax script). If your data is primarily static, Ajax is likely a poor choice.
Well, wouldn’t you know it … I might have gone too far. One of the applications I’ve been developing requires an expanding and collapsing hierarchy on the left side of the screen and two image viewers to the right. The goal is to provide simple navigation to users, who can find an image they want to look at, drag it into the viewing window and drop it in. They then go back, find another image and drop it into the second window for comparison. The drag and drop part of things seems a fine place to use some Ajax, as it is by nature more about the action rather than the data. But what about that hierarchical navigation system? Shouldn’t that be just hidden divs? Have I been caught in the trap of using the cool toy just because it’s cool?
Perhaps not (although it is so very cool). The trouble is that the complete hierarchy, expanded to its lowest levels, is gigantic. Loading all the information on the page every time results in some dreadful performance. It makes the whole application painfully slow. While it is less than ideal, perhaps, to hide most of the data from search engines, is exposure to the search bots worth losing all that speed? Or is there something missing here that I’m not quite figuring out yet about how to make this run quickly with hidden divs?
So until someone raps my knuckles for it, I’m sticking with Ajax on this one. There are other ways to bring bookmarking of compared images into the application, and I would rather have the application running faster than indexed by Google.
Am I completely off base here? What do you think?