Web 2.0

I cringe every time that I hear a management or business type utter the phrase, "Web 2.0" or toss the buzzword AJAX into a conversation as if they really know what that means. Using Asynchronous JavaScript And XML to dynamically modify the DOM of an HTML document to present an interactive user experience via the web is admittedly cool. But it's cool in a hacked together, "we're making the best of what we have available" sort of a way. It drives me nuts that people are actually considering building the future of their rich client applications around these hacked together technologies.

Have you seen how much HTML, JavaScript and CSS is necessary simulate a fairly standard UI widget like a tree view? It's ridiculous. And even more ridiculous considering that there are dozens of other technologies that already exist with very mature and rich UI and widget toolkits. It makes me laugh a little when I hear people talk about the latest features of some Web 2.0 application that they have just played with: "Wow, it supports drag and drop and context menus and tabbed views". Did everyone forget that these features have been a staple of desktop applications for at least the last 10 years?

So why is it that Web applications are becoming so popular? Why is "Web 2.0" is being touted as the next big thing? Behind all of the hype I think that it comes down to the fact that web applications solve 2 core problems that are often overlooked in Desktop programming:

1. No install required. All the user needs to run the application is a Web Browser and a URL. When the application is upgraded, the user instantly sees the new version the next time that they hit the URL. Think about how easy it was to 'upgrade' to the latest version of Google Maps as opposed to the latest version of Microsoft Office.
2. Universal Access. Web applications can be accessed from any computer, anywhere in the world with a web browser and a connection to the internet. There are no files, settings or software that are installed locally on the computer that you are running the application from. Wherever you are, your data is right there with you. It doesn't even matter if the computer that you are using to access the application is running a different operating system than you normally use. The web application does not care.

Those sound like pretty good things. So, why shouldn't we be excited about turning web application into the face of our rich client applications? Here are some things to consider:

1. Limited desktop interaction. Because the application runs inside of the browser it has a limited ability to communicate with your desktop or other applications. For instance: Do you wanna drag that file from your browser based email client onto your desktop? Well, you can't. Because one, the HTML platform does not allow for that kind of interaction and two, even if it did you would be violating all manner of security policies to allow the browser to write data to the local disk.
   
2. Bound by the browser window. Have you ever right clicked on something in a web application near the edge of the window and then been really confused when the context menu popped up behind the edge of the window rather than on top of it. Because the all HTML is rendered inside the browser window your entire UI is contained within this box. Why?
   
3. Connection Required. How do you read and write email on a flight from LA to Hong Kong using a browser based email client when you don't have a connection to the internet? Simply put, you don't. This may be decreasingly important as more and more of the world becomes connected, but until that time, this is still something to consider. Now, I've heard ideas kicked around about running a local webserver to serve up the Web Interface from localhost when you are disconnected. That's a novel idea but doing so really violates the whole benefit of web applications (i.e. that the application is available through nothing more than a web browser and that no software or data is required to be installed on the local PC).
   
4. Clumsy and Inefficient UI programming. Of course this isn't something that the end user cares about but it bugs me as a programmer. Why should I have to hack together a list view using a milllions of div elements when I can just use a list view widget from a UI library. Even as AJAX toolkits evolve and list view widgets are made readily available through AJAX UI tookits, it still bothers me that the computer has to work 100 times as hard to hack an HTML document to behave like a list view than it would to just render a native list view.
5. Web applications violate browser usability. A web browser is one of the most familiar pieces of software in the world. It is this very fact that makes web applications tempting. Every computer user in the world understands: back, stop, reload and bookmarks. The problem with Web 2.0 is that it violates nearly every one of these concepts. The back button doesn't work to get you to a previous state in a web application because you didn't travel to a new page to get you into the current UI state; you simply modified the DOM of the existing page. Stop often doesn't work, because many times most of the data is being requested asynchronously after the page 'shell' has been loaded from the server. Reload and bookmarks don't work because both of them are URL based and as previously noted, the UI state of the page is not persisted in the URL.

So what is the answer the here? I imagine a future (and I know that I'm not the only here) where applications are written using rich programming languages and UI toolkits, run locally on the desktop (instead of in a browser window), but are dynamically launched from a URL where the most up-to-date copy of the application always resides. Instead of hacking a document formatting language (HTML) to build applications, let's fix the problems in our existing application building languages to allow them to reap the benefits of the lessons that we've learned from web applications (i.e. Zero footprint install on local computer, automatically updating and central access to data).