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.

You're right that's not a real distinction.

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.

What is this open web thinggie with applications behind closed doors that I never get to see?

Google is just yet another big corporation that no longer needs to pretend to be the open source champion.

Likewise Apple is no different from the good old days of Mac OS. The openness that started with NeXT acquisition is long gone.

Open is only good as long as it sells, there is never the idea of making a better world for consumers just because it feels right or something like that.

I'm surprised by this comment. Google is still very supportive of open source, I don't think there is any comparison with other big tech companies. It's not just the still growing Google Summer of Code and Code-in programs[1], but the scope and number of open source projects that they publish and maintain: Android, Chrome OS, Chromium, V8, Go, Dart, Angle, Angular, PDFium, Guava, GWT, WebM...

By the way, I think the impact of Android (the open source project) is underestimated. There is a huge number of research and industry projects that are based on the open platform, not just phone and tablet apps but all kind of hardware projects.[2]

So when I read a casual dismissal of these efforts (by knowledgeable people like you) I feel bad for the engineers and managers that work to promote open source inside the company.

On the other hand, Google is the biggest force behind the shift to the Cloud, and that shift means more and more users using closed-source web apps like Google Docs instead of open source applications like LibreOffice, so there is that...

[1] https://code.google.com/p/google-summer-of-code/wiki/Program...

[2] As a random example see http://www.citlprojects.com/android_list.html

I was being a bit stronger to make a point about corporations and their relationship with open source.

There was a time I was one of such engineers that you mention, but eventually came to realize how company boards see open source and how little we could get in return.