Old problem: Downloading
New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded
Old problem: Installation
New problem: Installation. What if the user has NoScript? AdBlock? Mobile Opera vs. Mobile Safari vs. Chromium vs. IE.
Old problem: Special User Permissions; gate keepers
New problem: Proxies. Websockets. Anti-virus software. On-machine firewalls. Corporate firewalls. "Special" toolbars and plugins that redirect the browser.
The web is not a "software distribution platform". It is not a "distribution platform", because code is retrieved on-demand and run, and there is no simple way to "cache" that locally and re-run it. (Chrome App Store does not count, because it is antithetical to the model you've described). It is not even software in the traditional sense that you mean, because everything is inherently client-server, so most of the app lives on the server or in the cloud.
I don't understand your "installation" issue. A user with NoScript knows how to turn it off for a web application they want to use, and generally do so. They just want to retain control over JS execution. AdBlock is not related to actual application delivery, but revenue generation, somewhat orthogonal.
Having to support cross-platform quirks is also something that isn't unique to the web. If you support multiple versions of iOS for your app, you will hit similar issues. Not to mention if you wanted to actually be cross-platform and work anywhere other than iOS with the same app.
Downloading: easily solved with browser caching. This is still faster than trying to, say, walk a very non-technical user through downloading and opening an installer.
Installation: not an issue for most users. NoScript/AdBlock are a small percentage of users for most sites and since most of the web breaks that way, many of them have learned to recognize when their local system broke something.
Permissions: the problem in both cases are the gatekeepers and every single “new problem” you listed was also an old problem of equal or greater impact. If the gatekeepers are determined and unaccountable, they'll block everything either way. The difference is that the web side has a better security model and is more likely to be open because you're following a known precedent – Google, Amazon, Facebook, etc. have created enough demand that even the most fascist IT departments allow HTTPS. This is not the case for the traditional desktop model where every local software install is considered independently.
Unless you use an old browser, this is not a problem anymore. http://www.w3.org/TR/html5/browsers.html#offline
Exactly. The humble hyperlink is the most amazing thing about the web. It's simple yet devastatingly powerful.
I'm not a snob about the programming languages of the web. I don't care what language I need to learn to create content for the web, or what tools I need to use. The language and the tools will always be a means to an end — that is, the radical ability to provide free and instant access to any content for everyone on the Internet.
(from a blog post I wrote "why I create for the web": http://blog.neave.com/post/64669185529/why-i-create-for-the-... )
As a content delivery platform, the web is unparalleled, ridiculously good. I have paid for content (for example, NSFWCorp), and will do so again in the future.
But as a software delivery platform, the web is unproven if we are to be kind, and crap if we are to be honest. Web software is fragile, limited, and subject to the whims of the site maintainers, who may modify it without warning, or even remove it entirely (e.g. Google Reader). I have spent hundreds of dollars on native productivity software, games, etc. but I have yet to spend a dime on a website for its JavaScript.
That may change in the future, but I doubt it: any program that's a sufficiently good web app can be rewritten as a desktop app with more capabilities. Ultimately the web may be the go-to place for trivial or gimmicky software, but the most powerful apps will be peers to the browser.
Everything has to go through the centralised, closely guarded app shops. You'll have to go through silly certification processes to get your app into the app shop and if the platform owners (or some minion working in certification) feels like it, they can just remove your app without warning.
Compare this to a web app. You deploy the stuff on a web server of your choice, the user clicks on a link. Done.
The browser, html/css/js, is the most ubiquitous common runtime that has ever existed.
A lot of services have an iPhone app, an android app, and sometimes even a desktop program. But if you have a website, you get all of those platforms at once.
Sure you have to do things differently, usually more slowly, but you can do whatever you do on any device with a browser.
Browsers are themselves native apps, and therefore web apps will always be less capable than native apps, because web apps are subject to the one-two punch of the limitations imposed by native apps and the browser.
To the point of paying the fee of app in app, you're right that there will always be a penalty. But "will browser apps ever run as fast as native" is not really the right question. The right question is "will browser apps ever be able to run fast enough."
Finally, a clarifying point. When i said "do whatever you do" I meant that a website does the same thing in every browser, not that websites currently can do the same thing as native apps.