Finally some reason. Tried and true native methods are superior in just about every aspect except 'shininess' (the DOM-based styling of CSS) and simplicity for end-users that wish to not understand even the basic concepts behind the systems they use. There's no reason to build on the abstraction of a browser in order to build applications /except/ that it's ubiquitous/instant. This seems to attract developers that want to get users more than they want to develop truly excellent software.
Just about every other property of the web as a runtime makes a solid argument against its usability: stability (browsers are trying to implement a process model now because the JS/DOM sandbox/environment is not sufficiently robust to be depended on to not crash), standardization ("use webkit" or "use compatibility libraries in js" is a weak answer compared to real guarantees from fairly static and mature standards), efficiency (everything goes through at least: parsing, the DOM, javascript's broken (mostly-missing) typesystem, etc., all at runtime or application startup), and simplicity (more layers mean more complexity; we have various openGL standards and now also WebGL, implemented on top of one or more of them on each platform; javascript as a 'bytecode analogue' for slightly more usable languages such as coffeescript).
Throwing more code at problems has rarely resulted in an elegant and efficient solution, but that's the approach we're taking to try to get back the performance and featureset lost from running web apps in a JS/DOM container. We've wrapped enough fundamental OS features in JS libraries/DOM extensions/HTML features. It's time to end this nonsense and create a real standardized and generalized sandboxing model if that's what we want.
I consider ubiquity and instant-ness (i.e., accessibility) to be quite important aspects in which the Web platform is superior to native platforms.
I don't know what you mean by "truly excellent software", but I'd rather make imperfect, useful software than perfect software no one uses, wouldn't you? And it is certainly possible, and nowadays routine, to create simple, elegant, well-architected, maintainable, efficient, performant, small-footprint Web applications.
Yes, the Web platform has all kinds of warts and scars. In and of itself, all else being equal, they are of course strictly a bad thing. But the principle of openness and cross- and backwards compatibility--the principle that technical concerns must be balanced against community concerns--that is their root cause, I believe to be superior to any of the alternatives we've seen, which have given rise to proprietary standards, walled gardens, dependency and upgrade hell.
I agree that "throwing" more code at problems rarely results in elegant and efficient solutions, but disregarding existing community concerns, like legacy software or standards, rarely results in successful solutions.
Due to network effects, some developers can only create the app they want and have it succeed by making sure they can get users. Excellence for such software is dependent upon adoption.
I think the web could handle a fully re-imagined stack. So long as it adhered to well defined standards and kept dns, with buy in from the major browsers the two stacks could co-exist.
Just about every other property of the web as a runtime makes a solid argument against its usability: stability (browsers are trying to implement a process model now because the JS/DOM sandbox/environment is not sufficiently robust to be depended on to not crash), standardization ("use webkit" or "use compatibility libraries in js" is a weak answer compared to real guarantees from fairly static and mature standards), efficiency (everything goes through at least: parsing, the DOM, javascript's broken (mostly-missing) typesystem, etc., all at runtime or application startup), and simplicity (more layers mean more complexity; we have various openGL standards and now also WebGL, implemented on top of one or more of them on each platform; javascript as a 'bytecode analogue' for slightly more usable languages such as coffeescript).
Throwing more code at problems has rarely resulted in an elegant and efficient solution, but that's the approach we're taking to try to get back the performance and featureset lost from running web apps in a JS/DOM container. We've wrapped enough fundamental OS features in JS libraries/DOM extensions/HTML features. It's time to end this nonsense and create a real standardized and generalized sandboxing model if that's what we want.