While I agree with every aspect of your argument, your premise is wrong. You're limiting your mindset to your style of work and/or computer utilization. Web browsers do a great job of displaying information and transmitting it over the network. If your workflow involves displaying, creating or transmitting data then a web browser is all you need. However, the browser falls on it's face when you examine alternative tasks.

Specifically the browser is not designed to perform processor intensive functions. For instance, calculating a massive chart on a spreadsheet is something the browser can emulate, but not do well. Sure, you can have a 'spreadsheet' application via clever AJAX in a web browser, but a spreadsheet program is optimized for the task. Meaning, the code for the spreadsheet program is written to very specifically utilize the resources of the computer, whereas a browser plugin or the browser itself will never be able to leverage the machine's resources as directly or efficiently - if only for the reason that they will always have the browser overhead on top of it.

Many people nowadays find a computer without a network a useless hunk of plastic. But there are also people who continue to utilize computers away from the resources of the internet. For these people and their workflow, there is no good reason to use the browser as a 'launcher' for their applications - whether those are calculative programs or even simple word processing. Utilizing a program directly coded for the task is always going to be faster and more efficient, if perhaps not as dynamic. Additionally, even desktop apps are becoming network aware so that they can leverage many of the advantages of a browser (auto updates, etc.).

As far as code compatibility goes I think Java pretty much answered that battle cry years ago. Java apps will, by and large, deploy in a platform independent way.

Of course, all of this argument hinges on how you use your computer. For most folks you could offer them usable applications via the browser. But for a sizeable minority you're never going to be able to provide them a browser based application that will be suitable to their needs - witness the abysmal failure of the 'thin client' as evidence that not everyone wants remotely hosted applications.

The other factor you have to throw in is network reliability. If all your apps are delivered over the network via a web browser and the telephone pole outside your house falls over your computer truly does become useless. I know it's hard to imagine to most people in urban areas, but broadband in the US actually has extremely limited penetration outside of cities. Additionally the network is fairly robust, but it is by no means bullet proof. Having your modem go on the fritz and killing every computer in your house is a scary thought.

Ultimately I think the browser is a killer app, but it isn't the universal app you're making it out to be. There are severe limitations to utilizing the browser as a type of virtual machine, especially if you're launching code over the network. These, ultimately, provide compelling enough reasons that I don't think people will migrate to an all browser desktop any time soon, and even when it does happen it won't be everyone.

Good points justin, but I think we disagree about the relevance of the constraints you identify. We should be using servers and distributed computing for processor-intensive tasks. My browser shouldn't render spreadsheets, Google should. It's a better allocation of resources and energy, as anyone participating in the SETI-at-home project can attest.

I think some other people agree with me: http://googlesystem.blogspot.com/

Re "the abysmal failure of the 'thin client'", I think we're seeing it return. Like many other ideas tossed around in the euphoric late-90s, the prediction wasn't inaccurate so much as the timeframe was overambitious. I work on a thinner client today than I did 7 years ago, and I expect this trend to continue. With browser-based apps, you can get an office staffer up and running with less than $1K software investment, and not have to worry about whether or not they're checking important files into a central repository.

Broadband penetration is again today's problem, not tomorrow's. Many areas are skipping whole generations of connectivity (witness wireless growth in Africa, for instance). Last I heard, we're at 60% broadband connectivity, and I expect that number to grow with improving wireless technologies.

I agree that a pure-browser environment won't happen today, but I credit that lag to slow user adoption more than technological constraints.

A couple of other thoughts have occurred to me over the day:

1. Privacy. As soon as you rely on network enabled applications you are entrusting your data to someone else (even if only for a short time). Also, data is exposed on the wire unless you encrypt it which increases overhead (and even then it's not necessarily safe).

2. Hardware connectivity - browser models carefully insulate the hardware from the network because the network is an untrusted medium. As soon as you start talking about doing things like synchronizing your PDA with your data you move beyond the web browser because it cannot be trusted in this hardware model.

3. Offloading computation to a server is a tempting solution to many problems, but it runs into issues. While you might say "let Google's servers do your processing" I would reply "use open source and let your $300 machines do the processing because a) you already own them and b) it's totally free". Using open source software I can deploy an entire business for less than one that uses managed/hosted solutions. Moving the processing to the server means that you have twice the cost - once for your hardware, and once for the hosts hardware. You're lining that cost up in a column next to the price of software - but when the software is free that calculation skews in the other direction.

are you guys going to make out now?