The native versus web app debate conflates a number of different issues, which divide the two camps more due to history than any fundamental technical gulf.<p>Native apps traditionally run faster than web apps. Some operating systems use higher level runtimes than others and a few are based on HTML anyway, and on desktop the performance difference is arguably unimportant, but on mobile it doesn't seem to be going away anytime soon.<p>Native apps have to be downloaded and installed, and <i>trusted</i>, while web apps can be run instantly and are sandboxed. Why? There is no fundamental reason why I shouldn't be able to go to a URL and get an instant, properly sandboxed native UI, which then goes away when I'm done using it unless I explicitly choose to save it.<p>Native apps on most platforms are moving to an app store model which, as mentioned in the article, integrate things like payment and have gatekeepers that can benefit users. But there is no reason web apps can't have these features, and Mozilla is working on a curated marketplace and a payment API for web apps.<p>Web apps can be deep-linked into, which many web advocates claim is critical, and generally follow more of a page metaphor than native apps: I can open any two locations in the Gmail UI in tabs rather than being limited to what, if anything, the app author specifically designed to allow multiple parallel views, I can bookmark a location in the UI (yes, there is a rut of poor design in between traditional server-side apps, which are naturally bookmarkable, and well-designed client-side apps like Gmail, which manually implement this feature, but the culture encourages making it possible). But why shouldn't native apps intercept a specific URLs and provide an alternate implementation for deep links, and why don't native UI toolkits naturally support a page metaphor?<p>Web apps are traditionally more hackable than native apps. There is a culture of browser extensions that hook into page scripts and modify them without any formal API, but similar functionality, while usually possible, is rarely popular for native apps, except perhaps on jailbroken iOS. This is to some degree an inherent result of web apps being limited to high level languages, but improvements in tooling and changes to culture could definitely make up for this, and could significantly improve native apps for power users.<p>And finally, at their best, native apps follow a specific platform's UI conventions, while web apps are sort of a global compromise. Out of all these differences, this is the one that actually makes sense: at best, native apps will give you a choice between several good but opinionated UI paradigms, so that different users will have different preferences but will often prefer one of the options over the generic version.<p>But every other one of those differences represents a compromise I, as a user, currently have to make when I choose between a web app and a native app. Whether whatever technology or technologies win out in the end are based on JavaScript, C, or something else, I think that "web vs native" is just a symptom of a platform war that still has a long way to go.