In an informal panel discussion before the MobileBeat 2009 conference, Google engineering vice president and developer evangelist, Vic Gundotra, said "that the web had won and users of mobile phones would get their information and entertainment from browsers in future." (Financial Times Tech Blog)
Saying "the browser [...] will become the platform that matters," Mr. Gundotra pointed out that browsers built around Webkit would have access to information provided by GPS and accelerometer hardware. Interestingly, both Google's own Android and Palm both make use of Webkit in their respective browsers.
His main point is about the expense of supporting several different operating system platforms, versus the expense of providing a single, cross-platform web application. And, wherever that argument applies, he's certainly right.
My point is that this argument isn't as universally applicable as it might seem.
For example, processor intensive games, commonly done in OpenGL, aren't going to be delivered as web applications anytime soon, because their performance would suffer too much as compared with the same games delivered as native applications. Even if the more important mobile device operating systems all provided both OpenGL and some means of making direct use of it from within their web environments, the chances that the exact same code would run properly on any two is vanishingly small. In any case, game developers have been shifting away from direct coding and towards the use of cross-platform development environments, that provide the tools and performance they need while taking the pain out of supporting multiple platforms. While it wouldn't be what Gundotra is talking about, a hybrid system you might see would couple a native game engine app from the provider of such a development system with web apps that run within the environment it creates. Combined with a web-based framework, like SproutCore, that approach could be very powerful. (Bingo!) Game developers will support as many platforms as makes sense in the market, variations on the web included.
Performance is only one reason for preferring native applications to web applications. There's also the matter of general functionality. I personally lost most of my interest in developing for the web when I discovered there was no standard means of generating synthesized sound in real time, and while workarounds might exist they were both platform and browser specific. I decided I was better off to pick a platform and develop for it instead of for the web. So far as I'm aware, that situation has not yet been remedied in HTML5.
There are good reasons why native applications will continue to have more functionality available than do cross-platform web apps, for some time to come. First, at least in Apple's approach, vending all native applications through its iTunes Store, problem apps are quickly identified and those that remain on the system for more than a few days can be considered trustworthy, far more trustworthy than a web app from some random source. Hence the walls of the sandbox around web apps must necessarily be higher than those that surround native apps.
Almost as significantly, cross-platform web applications depend upon web standards, which require agreement among vendors, which takes time. Any new development will nearly always appear in one or more native app toolsets (long) before it appears as a web capability enjoying widespread support. Consider that the animation capabilities included in HTML5 were first introduced to the market with the advent of the Amiga computer, in 1985, ten years before the web went mainstream.
Then there's the advantage of working with tools you already know. Apple has attracted 100,000 people, with widely varying degrees of programming experience, to their iPhone platform. That's very likely many millions of person-hours spent studying documentation, learning how OS X works, an investment many won't be eager to walk away from to take up HTML5 instead. For more than a few it won't matter at all that their apps only run on iPhone OS devices, and not on everything out there.
And let's not forget that the cost of getting into the web app business includes either running your own continuously connected server or renting space and bandwidth on someone else's, whereas an independent developer working from a coffee shop can get an app published on the iTunes Store, and Apple handles all of the nitty gritty details, for a mere 30% commission.
Nevertheless, there will be situations where web apps make more sense, and it's good to see the standard finally moving forward.