You're absolutely right. I wrote that node in haste and now I can repent at leisure. But let me clarify. I certainly didn't mean that Ovid should blithely use every DHTML trick in the book. What I did mean was that if you have a page on which the user is entering data, and you want to update some subsidiary data on a different page, it might pay to put up the entry form for that subsidiary data in a popup window. And once the user has entered that data, how do you communicate that fact to the parent window, and how does the parent window display the newly entered info to the user? JavaScript and DHTML. That's really all I was trying to say.

You'll end up having to support ten versions of your code for different browser/OS configuratons.

That's certainly an issue when you're writing a web app for the general public, but when you're working on an intranet-based app that a strictly limited group of users will access, you probably have a certain amount of control over which OS and browser the users will be using. I don't think it's unreasonable to write platform-dependent code in such a case.

One good idea is to spend some time on sites like Expedia, JetBlue, Amazon, Southwest Airlines and other web apps that have to maintain a lot of state and allow for users to do lateral navigation. Steal ideas from them, notice how they do error handling, UI design, and so on.

Absolutely. But also pay attention to where they still screw up. Some of the most annoying experiences of my online life have come when trying to price airfares. If Expedia and Travelocity and their kin work smoothly now, it's only after YEARS of sucking, and falling prey to some of the worst pitfalls of CGI-context state maintenance.