Less pedantically, I distinctly remember a generation of applications that were thin "webifications" of desktop apps. These attempted to build a core application independent of the delivery mechanism, precisely as Bob suggests. All of them ended up hopelessly snarled in state management nightmares. They didn't scale, tended to lock up badly (due to database transactions), and were painful to use because they did too many page reloads.
At the root, I think the architecture of a system must balance the forces acting on it. Some of those forces emerge from the application domain, but many of them also emerge from the technology domain.
One of these delivery media responds best to command-oriented transactions that do not rely on keeping state in memory. The other works best when state is kept in memory for rich interaction. With so many fundamental forces in opposition, how could we expect the architecture to be the same?
Would one ever build web applications out of a bunch of .ocx'es in containers? Would one ever build a desktop application out of hyperlinked resources? Only as an exercise in perversity. This isn't because we have bad frameworks or leaky abstractions (though both exist). It's because the fundamental nature of desktop and web applications are different. Ignoring that entire aspect just because it doesn't come from the business domain is irresponsible.
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).