November 1, 2006 — Have you looked at the code behind AJAX implementations? Forget about spaghetti code. We're talking about shredded wheat. We're talking about heaps of jumbled rubble.
I'm a wholehearted believer in AJAX. Many of the user interface examples that I've seen are incredible. While there's no mistaking AJAX apps for true native applications, well-designed UIs are an order of magnitude more responsive and intuitive than classic Web applications. I've seen some, though, that are pretty terrible. Alas, most Web developers simply aren't good UI designers. They're far too used to dealing with the constraints of standard HTML and CSS, and in thinking about postbacks, to know how to use the freedom that AJAX offers.
That's one problem with AJAX, but I dare say it's not the biggest. The challenge is that AJAX is being retrofitted to existing Web applications using immature tools, immature libraries and immature runtimes. It's a kluge, a hack, a hairball (to quote Scott McNealy, albeit from a different context).
Many developers and software architects-myself included-think that elegant code is more than aesthetically pleasing. Code that's well designed, well architected and well written is easy to read. It's easy to understand. It can be tested, tuned, debugged. It can be extended. It can be maintained.
AJAX code that I've seen, for the most part, doesn't fit any of those considerations.
As I write this, I've just finished editing a special supplement on AJAX development for SD Times. You'll see it with your Nov. 1 issue of the newspaper, and you'll also be able to download it from sdtimes.com. In that supplement, a number of tools providers talk about their AJAX controls and libraries. They make an impressive case for why enterprise developers shouldn't roll their own AJAX plumbing, but should instead go with packaged solutions.
Despite the lure of canned software, I am fascinated by the technical underpinnings of AJAX. I'm starting to dig into Microsoft's Atlas implementation, which just came out as an official beta (as opposed to the early Community Technology Previews). I think they've done a good job of removing a lot of the complexity, mainly by leveraging their tightly integrated stack. Even so, the Atlas code samples that I've seen still look like shredded wheat.
Three points, therefore, to close with: First, take the UI design seriously with AJAX development. It's not standard Web UI development, or at least it shouldn't be. Second, look at packaged offerings for enterprise deployment, to reduce the amount of plumbing. And third, keep an eye on the code. AJAX development shouldn't mean putting up with inelegant spaghetti code or coughing up a hairball.
Comments