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.
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%.