I've never understood what "the open web" has to do with Javascript vs. native binaries.
Right now, we write in a variety of languages (ClojureScript, CoffeeScript, etc.) to produce opaque minified+concatenated blobs of JS-targeting (or asm.js-targeting, even) object-code. Sometimes, we just take raw machine language and re-encode it with Emscripten! Nobody can read any of this without a process that exactly fits the term "decompilation."
Effectively, then, in the current model, the browser is just obeying this contract:
1. When you encounter a <script> tag, download the specified binary (for the Javascript Abstract Machine, the world's most verbose ISA);
2. resolve its CORS origin to calculate a default permissions set, and boot it up within a fresh VM/container/sandbox circumscribed by that permissions set;
3. allow it to manipulate various browser APIs (e.g. the DOM, WebGL);
4. give it the ability to request additional permissions (for e.g. storage, or location information) which you will then prompt the user for.
So what's the difference if the binary is encoded in some other way? What's wrong with Native Client, or Android, or even Java, if it's run under this same "contract"? Javascript is no more open or closed than any of these. They're all relatively opaque and require decompilation to comprehend or learn from. They all only act through browser APIs. They all talk to servers using "open web" REST requests. And--this is key--a web browser could be taught to debug them in just the same way it debugs Javascript.
I would say there's a spectrum though, even among JavaScript apps, of standards adherence. For example you could draw your own glyphs on a HTML canvas element. That would still be "the open web" in some literal sense, but it's less of a web app in that case and more of a JavaScript app that can run in the browser.
You're right that using the browser as the runtime is a key requirement for an open web app, but I would add a bunch more criteria:
- every user-relevant resource has a URL.
- content is rendered with the semantic tags HTML provides when possible
- the app is performant in common browsers
- you use HTML and CSS in a way that things degrade gracefully on older browsers
- you use standard interactions (hyperlinks, forms) wherever possible and implement your own widgets only when necessary.
By these criteria many pure HTML apps are not good open web apps. The old practice of rendering text in GIFs to get typefaces and anti-aliasing was a step away from "the open web".
I don't think it's strictly a technical line people are talking about. It's a set of conventions that let us write code that is cross platform and gets many benefits for free (sharability, printability, responsive design, etc)
There are many apps that don't consist of representing and manipulating hyperlinked documents, though. For example, games. Would Angry Birds be better if it was built out of DOM nodes? Would an night-sky astronomy visualization app? Would a synthesizer?
These are the types of things people make Chrome apps for. And frankly, I don't see the advantage of those being built out of "standards-conforming semantic markup" versus just manipulating the browser's APIs directly.
Right now, we write in a variety of languages (ClojureScript, CoffeeScript, etc.) to produce opaque minified+concatenated blobs of JS-targeting (or asm.js-targeting, even) object-code. Sometimes, we just take raw machine language and re-encode it with Emscripten! Nobody can read any of this without a process that exactly fits the term "decompilation."
Effectively, then, in the current model, the browser is just obeying this contract:
1. When you encounter a <script> tag, download the specified binary (for the Javascript Abstract Machine, the world's most verbose ISA);
2. resolve its CORS origin to calculate a default permissions set, and boot it up within a fresh VM/container/sandbox circumscribed by that permissions set;
3. allow it to manipulate various browser APIs (e.g. the DOM, WebGL);
4. give it the ability to request additional permissions (for e.g. storage, or location information) which you will then prompt the user for.
So what's the difference if the binary is encoded in some other way? What's wrong with Native Client, or Android, or even Java, if it's run under this same "contract"? Javascript is no more open or closed than any of these. They're all relatively opaque and require decompilation to comprehend or learn from. They all only act through browser APIs. They all talk to servers using "open web" REST requests. And--this is key--a web browser could be taught to debug them in just the same way it debugs Javascript.