What I miss in all those discussions regarding JS, asm.js and PNaCl is that the web is the best software distribution platform we have by a huge margin, this is really its overwhelming killer-feature. All the user needs is an URL. No "downloading", no installation, no special user permissions, no app shops, no gate keepers, no walled gardens, and everything is automatically multi-OS and multi-CPU-architecture. The web as a runtime platform may not be ideal, but the web as a "software distribution platform" rocks. For this I'm even happy to give up a few CPU cycles. And no platform should be tied to a specific language. The more choices there are, the better.
Have you actually shipped a complex codebase to the web? There are a TON of major issues which are just as bad:
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.
None of the things you've listed are actually really problems, or have well-known solutions. HTTP caching solves the downloading problem for most classes of application. You can also run apps locally with app-cache and local storage (and in the future IndexedDB), though I'll grant that this isn't absolutely perfect today.
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.
http://www.flohofwoe.net/demos.html, these demos are about 150k to 250k lines of C++ code, and are about 700k to 1.5MB downloads, the same as zipped native executables. I'm also on the team which does a web-based MMO which is running for 3 years now (not done with emscripten though), so I'm aware of the problems :) It's still miles better then closed platforms.
Having worked on both traditional and web projects, I disagree with “just as bad”. In every case, what you're talking about is easier to solve on the web than off-line.
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.
> All the user needs is an URL. No "downloading", no installation, no special user permissions, no app shops, no gate keepers, no walled gardens...
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.
I noticed the shift from the parent's "software" to your "content." The distinction is critical. Most web pages are content, i.e. what's worthwhile in them is their media (text, images, video, etc.), and not their code. What draws us to HN is its content, and we appreciate its minimalist aesthetic, i.e. if it it used WebGL or something it could only be made worse.
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.
You're right, its more about software, less about content (but the line between software and content is blurry anyway). But it is becoming harder and harder to actually distribute software to user's desktops or mobile devices since these platforms have either been closed from the beginning (iOS, game consoles), or are quickly starting to become closed (OSX, Windows8). You can no longer simply send a download link to your users, or have your own download website with a 3rd party payment provider. The user has to jump through a comical amount of hoops to get the app running (Do you really want to run this extremely dangerous software downloaded from the interwebs? Administration rights are needed to install this software!, etc etc etc etc... its a travesty).
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.
It's not the case that a web app is capable of doing "whatever you do on any device." The browser exposes a tiny fraction of the actual device capabilities.
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.
Im not sure your contention that browsers will always be hamstrung is true, time will tell, but proposals for HTML spec camera integration, gps integration, etc are alive and well.
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.
