From a philosophical standpoint I'm rooting for an open, interoperable web as much as anybody. As a programmer though it's hard to feel much enthusiasm for such a fragmented, baroque, and inadequate toolkit.
From a philosophical standpoint I'm rooting for an open, interoperable web as much as anybody. As a programmer though it's hard to feel much enthusiasm for such a fragmented, baroque, and inadequate toolkit.
However, it also defeats the point of using HTML in the first place. When you abstract everything away to make the development environment sane, you abstract away the features that make HTML useful, like the ability for the markup to be interface agnostic.
I often feel the browser should become what Java was intended to be and let HTML and CSS be one application of that system. It is the direction we seem to be heading. Giving the applications a more direct path to the hardware is the natural evolution going forward. Why are we fighting the HTML/CSS layer? It is surprisingly accommodating, but adds a lot of needless overhead.
Now the experience is much broader, many users will have a smart phone, maybe a Mac at home and PC at work, then throw in the use of web applications like Google Docs and the whole interface landscape has become much more diverse.
Leaning towards the web as a user interface guide makes as much sense for most developers as anything else.
One thing the richer mobile toolkits leave out, that drove the web's success, is the "view source" feature, a tremendous way to on-board new developers.
Browsers are at a disadvantage because they need to have a ton of security built in because people casually go to websites, whether or not they are malicious, but are more hesitant to download an app. Also if an app is malicious it can be removed from the store, taking down a website on the other hand is not an easy feat.
Maybe it's just me but I also find that Java's static type checking eliminates a lot of the dumb mistakes I tend to make in JS/Ruby/Python.
(See also Java/GTK/... cross-platform desktop apps)
Having said that, we do native apps as well; on iOS the experience is better, but you'll be paying a bit more to get it to that point. While on Android, it is just very very hard to get something as nice looking as we can do it in HTML5. It can be done, but personally I don't think it's worth it. For our development process we use 'business value' as a key indicator of deliverability and the difference between the PhoneGap apps and and native apps on Android do not deliver enough (actually any) business value to warrant the higher price tag.