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.