The future of AJAX web applications

There’s an interesting opinion up by Joel Spolsky, a software developer and founder of FogCreek Software, about where the direction AJAX-based web applications are headed. He makes an interesting, and I feel very apt, comparison with the olden days of mainframes and Lotus 1-2-3, and the current state of the interactive web. For instance, he likens the idea of sites like Google’s Gmail with Lotus 1-2-3, where the development team spent all of their time writing code and optimizing it for the current day’s limitations, rather than looking ahead and adding new wiz-bang features that would give them their “long-term competitive advantage.”

And I think Joel is completely right. Gmail, for one, has been stagnant for the last three years or so, and haven’t been preparing for the future. Check out this blog article from Lifehacker about a comparison between Gmail and Yahoo Mail. Their conclusion? Yahoo Mail has spent the last two years innovating and adding all sorts of new features, while Gmail has very little improvements (except, perhaps, incrementally increased storage levels).

As Joel has pointed out, the future of web applications is going to involve a standardized interface, providing UI-level features, interoperability, and a common platform for development. And there’s evidence of this happening. Several frameworks have come out recently that are generally very good: my favorites are YUI and prototype/scriptaculous. Very helpful, though the YUI is, I think, especially useful, as it provides a lot of very clean, useful interface-based functionality perfect for developing rich applications. But, it’s far from lightweight. And Joel’s point is: that’s okay.

I think we’re nearing a critical mass when more online software development will use an existing framework like YUI, so the common code between these sites will more likely be in users’ caches, therefore speeding up load times and reducing bandwidth costs. And, on top of that, there is likely to be further innovation to speed this up: building some amount of the framework code into browsers, say, or different, longer-lasting caching mechanisms strictly for Javascript framework files, or a whole number of other options.

Whatever happens, I think the biggest winners over the next several years will be with the developers who spend their time making the best applications, and let others (like browser developers) worry about keeping it fast. That’s not to say, “go out and make super-slow sites”, but rather to realize you shouldn’t spend all your time developing faster applications while neglecting features and other forward-looking progress.