In the beginning we had the Web 1.0. Each time you clicked on an item or hit Post, the request went round trip to the server, then back to the client and re-rendered. This was slow, looked nothing like a real application, and caused people to become alcoholics, ActiveX users, or -- worst of all -- Flash developers.
We were then given AJAX, which bore us Web 2.0. This allowed us to create "real" Web applications that didn't require rooting our browser for the whole Internet. The purists started to develop single-page applications, and the industry was swarmed with young 20-something programmers with fauxhawks.
The whole AJAXian jQuerian revolution has given us Angular Backbones, and the younger generation is inventing new things -- like unit testing, debuggers, and code analyzers. While I jest, I've been hiring these folks for the last couple of years, in part due to customer demand and in part due to the fact that this is the only decent way to create a good-looking, responsive app that doesn't require installing things or having to commune with Satan or -- perish the thought -- Microsoft System Center Configuration Manager.
Meanwhile, oddly in parallel with the AJAX Web-2.0 revolution, a weird Neanderthal was born. Developed from the MVC or "Model-2" framework, along with use of the HTTPSession for sever-side state management, this strange class of frameworks made server-side applications even more stateful. Indeed, you need a few data centers to store the browser state (the state of each tiny little control on the Web page) and user state for five users. There were several incarnations of this; the first was Spring WebFlow. The second was JBoss Seam, and it was largely standardized as WebBeans.
Several attempts were made to make this stuff smell, look, or taste a bit more like a Web 2.0 application or brand it with AJAX sprinkles -- although when the page posts or an entire freaking state tree is transferred, the lag generally clues users into the idea that perhaps this is not a real AJAX application even if it uses the XmlHttpRequest object. This stuff attempts to solve a perceived problem of the disorder of actions causing random navigation to random places by imposing a state machine representation of your sitemap. In truth, it is a little like Gopherizing HTML to prevent disorderly linking.
Why this stuff emerged from the primordial soup, I will never know. It has made me a lot of money in scalability consulting (where I pretend that the root cause isn't the technology in order to avoid upsetting you while advising you to move everything into "request" or "flash" mode). It's a path that diverged from the pendulum swing that is the evolution of the Internet, or at least the World Wide Web part of it.
It isn't Web 1.0 or Web 2.0 -- it's Weberthal. This stuff has been in decline for years, but you should do your part for evolution (or for your deity if you don't believe in evolution) and start helping Weberthal along to extinction.
This article, "Web technologies that deserve to die," was originally published at InfoWorld.com. Keep up on the latest developments in application development, and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.