I pretty much agree with you - though, I have to admit, things like GoogleMaps, GoogleDocs, are pushing that cut-point further each day.

I know a _lot_ of people who use the GoogleDocs Spreadsheet tools as their only spreadsheet, and gmail is a pretty powerful email client. I'm going to suggest that the cut point is at about 50% of the applications out there today, if we can include code that can be run offline by your browser as well. HTML5 is going to radically move that cutpoint.

Many of the new applications that we use in our company, Jira, Remedy, Confluence, Bamboo, are being built as web applications.

Microsoft Excel on Windows is still about 10x better than any spreadsheet Application out there for people who really need power, but, for 95% of the population - a lot of the web apps will serve them just fine.

Now - where I think we can all agree, is that the _backend_ of all of these webapps, are well and truly going to be thick server apps for the forseeable future.

I agree excel is a better app than google docs. I find the argument that it's just fine for 95% of the population worrying. This doesn't say that the browser is a superior technology, but an inferior technology that 'will do'.

If we turn the tables and I was advocating non web apps because they're good enough for most users, well I'm sure what the reaction would be (I'm being downvoted for advocating a technology that is superior and easier to develop for at the moment - but it seems my water is kool aid free).

I'm not disagreeing that some web apps are useful, and indeed I use them regularly, I'd put the point at closer to 5%, and if I exclude google search we'd be down to 2%. I'm a business user and I'm happy to pay for applications that I use and provide value. But the idea that is being pushed to new developers is that all future apps should be web apps is damaging to the profession and is incorrect.

If we look at the proportion of html based web apps that generate value and exclude search it would be interesting to see what percentage value of application revenue would be generated - 1%? 10%? more, less?

I also note the applications you mention are business apps with a html client and server backend which I agree are suited to an html client. Although I prefer (as do many others) a more responsive native client front end. This uses html as a more advanced 3270 terminal really, which is fine but it's not cutting edge, no matter how it's presented.

So much more could be achieved by using native front ends and just forgetting about the web browser. Look at itunes as an example it's a web enabled app and uses native code.

Perhaps I'm biased - I work for an Enterprise Focused Organization (about 100 Engineers) that builds applications for Utilities. Outage Detection, Network Monitoring, Advanced Meter Reading. We never even considered building any of these tools as thick apps - 100% Web Apps. The Tools we use to manage the builds, file the defects, track customer requests, monitor networks - all Web Applications.

But -your point has merit when I look at the _number_ of applications I use - Around 25 in a given week (Terminal.App, Mail.App (Irony. :-), Colloquy, Adium, Excel, Visio, RemoteDesktop, FireFox, VMware, iTunes, VLC, CiscoVPN Client, Calc, Wireshark, etc...).

I guess, at the end of the day, the question is, what type of user are you - Those of us who are developers, SysAdmins, may be more likely to use a lot of thick clients, whereas people who have a limited number of tasks (Customer Service Representatives, Purely Administrative) may be be more likely to use Web Tools.

I make the argument about technology that "will do" - because I recognize that most people aren't you and I, they really just want to use their computer for a very limited set of tasks and move on. But, your point about turning the tables is well made. Overall, we should recommend the best tools for the job.

It's just that Web Applications, once built, are so easy to deploy across the enterprise. It really is hard to build a decent application that can be (A) Rapidly Deployed to everyone, (B) Be maintained with patches on everyone's system, and (C) Be useful on Windows, OS X, and Linux, _unless_ you deploy it as a WebApp. For some reason, Java Apps never really took off (I'm not sure if you consider Java Apps to be Web or Thick Client - I think they are in the middle.)

And, I agree with you in terms of where I get Value - at the end of the day, when I _really_ need to get some serious content creation or analysis done - It's Excel, Visio, and, interesting enough - my local shell. I'm astonished how, 15 years into technology management, I use awk on 10 Gigabyte files to do critical work. Definitely not a webapp.

So, I guess after reading your analysis, I probably agree with you more than I disagree. In particular, "html as a more advanced 3270 terminal" brings it home for me. The reality is, when I need more than just a terminal onto a back end application, I _do_ use a local thick client, and, I'm guessing that if most of the HN audience reviewed their work habits, they do as well.

How interesting.

I agree it is unfortunate that Java apps never took off, but that may change, or something like java will replace it. Maybe it was a technology before it's time - or promised more than it delivered, it did have it's flaws. Silverlight and flash are trying to take that place, but no one really wants a proprietary solution.

As for the browser it has it's place, but it's not going to replace thick clients and OS's at least not in the near future.

You're making some good points and I give you credit for starting this thread taking a karma beating for it :-) You definately get my upvote.

But here's why I think you might be wrong. Your argument rests an one assumption, which is that the big datasets, the gigabyte size video you're editing, the huge science data set that you want to analyse, etc, originate on your PC.

That used to be the case traditionally and it continues to be the case quite frequently. But I think it may be the exception in a few years time. Video cameras could simply buffer the recordings and stream it right back to the data center. Satellite pictures and other kinds of scientific data could also be stored directly from the sensor to the data center instead of being stored on some PC and then uploaded for sharing purposes. Other types of data that is being analysed today is already stored on the backend and cannot be downloaded as a whole (RFID data, financial trading kind of stuff, etc). It has to be manipulated and analysed on the server.

If most data lives in google's data center the equation changes. It might be impossible to download the entire dataset and then edit it on your PC using a desktop app. The bandwidth argument suddenly favors the browser. High powered desktop computers could be relegated to a few special purpose tasks. Most users might not own machines capable of manipulating massive datasets or video files.

And then you have things like google's native client. It's not like everything client-side has to be written in JavaScript forever. There's not much left that a browser equipped with something like native client cannot do provided the data lives in the cloud.

I agree that more and more data will be stored on servers and will be processed by chunky server code. The point I'm wondering is the browser and html a good tool for accessing and processing this data? I would say no, that a native code app that uses the web infrastructure is superior - a web enabled app.

More so I think there's a lot of time being wasted on trying to get the browser to do things using html as a programming model when it's a lot easier to write native code apps and just forget the browser - call it web 4 (or 3 I've lost track of where we're at number wise).

There's no reason that the browser can't be a component of that web enabled app, just html is not the only way to write applications.

Strangely I was talking to the owner of a medium sized ISV who was relatively technically literate but not a developer. I was saying how you can deliver apps using a native app, the response was 'but don't you have to use html?'. Currently the web is the browser - this is not true, tcp/ip and other protocols existed before the browser, and there is absolutely no reason that http and html has to be the only way we communicate with servers. Indeed I belive the blindness of tying everything to the browser is costing a lot in development. It's time to move on. Keep the browser for what it's good for but don't try and shoehorn everything into a html solution.

If in your argument you say 'web enabled application' instead of browser then I agree 100%.

The main thing the browser has to offer for applications over any binary is a broader set of API functionality. With a binary you have a nasty OS-and-library-dependency rigmarole to go through - with additional hairiness when you're talking about cross-platform applications - and you have to spend more effort to maintain it because every OS changes over time. If it can be built in JS and HTML, you gain a powerful amount of portability, even if you've only written to support only a subset of browsers, and you have some assurance that the code will remain backwards compatible for a very long time to come. Those are both huge wins, and they trump most other concerns for content applications, even if the browser paradigms cause some amount of hoop-jumping to take place.

If you're talking about "infrastructure," of course - compilers, databases, servers - those are reflective of the system internals, so the lower level environment is necessary.

But outside of that domain, browser-apps are the lowest-risk platform available. That's good engineering and good business.

I would really dispute your first statement. The brower has a very limited API compared to an OS.

Cross platform app development is difficult. But then so is getting a complex web page to run on multiple browsers. To my mind cross platform development is a lot more predictable than cross browser development, but I concede I may be in the minority with that one.

But the initial discussion that everything will be done in the browser seems to have gone out the window, so I can live with some things done with a browser and thick clients to do more complex tasks. In time the browser may start to do some of the things a thick client can do, but I won't hold my breath on that one.

Regarding your idea of data being uploaded instantly, or nearly instantly, at generation: I think this is spot on, but I don't think (and I surely hope not) that the data will be uploaded to Google's (or anybody elses, in particular) servers.

Instead, I think (and hope) that the data will be seeded in a manner similar to Bittorrent, and stored in a distributed way.

The big reason I think Web apps will succeed, though, is that it's a common API. HTTP might not be the best protocol for everything, ever, but it's a pretty good protocol. JavaScript might not be the best language for everything, ever, but it's a pretty good language.

The things that our OS:es do for us today, they can keep on doing, and that can be written in C or Java or assembler, but they will eventually have to expose that functionality to the Web platform, if anybody is going to use it.