Shared publicly  - 
At least it is not out of band, but this still strikes me as a slippery slope towards the mess Internet Explorer is dealing with (and Word has in the past). Not very webby, ECMAScript.
David Baron's profile photoIan Hickson's profile photoBrendan Eich's profile photoPhilip Jägenstedt's profile photo
Having N code paths where you anticipate only 1 of them being frequently run (and the others less so over time, but they will have to remain to work) is very problematic in my opinion. Quirks mode should have made that clear.

And this can be worse, as a) ECMAScript is still being developed and b) it seems you can use multiple versions together from different scripts.
Boo for versions, but what alternative should one suggest? Keep extending "use strict"?
Just live with past decisions. I wouldn't even have done "use strict".
But the alternative isn't living with past decisions, it's everybody switching to a new language because ES won't introduce new syntax for lambdas, classes, etc. Versioning pragmas are the lesser of the evils, imo.
Why is it more evil for everyone to switch to a "new version" vs. a "new language"?
Is it going to be "use version 6" or unquoted? If it's the latter, isn't that just going to cause a syntax error, just like actually using the new syntax would?
It's not more evil for everyone to switch to a new version vs a new language. It's exactly as bad. That's the point.

The right thing to do is to have a language that is both forward- and backwards-compatible, like CSS and HTML, so that you can mix new features and old features without having to select a processing mode.
+Ian Hickson, Is there a clear, concise argument somewhere that demonstrates this is indeed the case? Not trying to argue, just looking for a link to point people to.
Demonstrates that what is the case, exactly?
That ".. the right thing to do is to have a language that is both forward- and backwards-compatible, like CSS and HTML, so that you can mix new features and old features without having to select a processing mode."
How are you going to introduce a feature like lambdas into ES in a backwards compatible way? Doesn't seem like you can, so are we giving up on ES as a language people use directly and just accepting it will be a target for CoffeeScript, Dart, etc?
+Geoffrey Sneddon you could have try/catch parse-time constructs or just live with the fact that the script will not compile in older user agents (which you should be able to detect using window.onerror and then do something).
How would you introduce these try/catch parsing constructs into ES in a backwards compatible way? And if all you're going to do is catch errors and fall-back, why not just simplify the process with a version indicator that lets the browser skip trying to parse and execute code it doesn't understand? I get the whole versionless web, living standard idea, but this seems like applying the principle to the point of absurdity, and allowing theoretical and philosophical objections override what is the most practical option for evolving ES.
Forwards-compatibility is something you have to build in to the language as soon as possible, ideally at conception. With CSS, it was designed-in and later tightened up based on what implementations had done. In HTML, it wasn't designed in, but UAs essentially implemented it and we were able to retrofit it in a backwards-compatible way with the current spec. With JS, you'd likely have to do a breaking a change once to introduce it.

It's relatively easy to bake forwards-compatibility into an imperative language, though it's not something most languages do. You just define some basic syntax, e.g. that braces and parentheses have to match, possibly with some basic rules for demarking string literals and comments, and then you say that if within one of those blocks the syntax can't be parsed according to the latest rules for the language, then it evaluates to a well-defined thing. e.g. you could say that it evaluates to something which, when its value is obtained, throws an exception.
+Ian Hickson Scheme-like macros would help make EcmaScript future-proof. They have been discussed a lot, but it turns out they are very difficult to make right.

FWIW, block lambdas <> would help a lot, too (it even allows to define `while` as a function), and it is much closer to getting harmony status. It just lacks community acceptance.
I don't think the analogy with HTML or CSS is very helpful here. In both of those cases graceful degradation is possible and useful, e.g. using the child content of <video> or just ignoring border-radius where those features are not supported. For ECMAScript, throwing a runtime exception seems decidedly worse than a parsing error – the script still won't work but there's a good chance you won't notice. For whatever reasons, I don't see Web developers complaining about ECMAScript's draconian error handling, while things like GWT and Dart try to make it even stricter.

Going back to the original issue, we are stuck forever with the parse- and runtime mode switch that is "use strict". Does ES6 change the semantics of any valid ES5 syntax, or why is a new mode switch needed? (Also, is "use version 6" quoted or not?)
+Philip Jägenstedt Yes, ES6 breaks `typeof null` (it makes that return the string "null" instead of "object").

Anyway, versioning in Harmony was intended for graceful degradation in non-Harmony browsers. Quite frankly, it is unclear for now what that means.

Maybe there'll be a possibility of testing for support of Harmony, and if there is no support available, a Harmony shiv script will be loaded and will transpile to ES5 code.

Maybe we can get finer surgical operations on our code, like replacing the use of proxies with _noSuchMethod_ in Firefox to avoid the overhead of a full Harmony shiv.
There are other, more significant, runtime changes than "typeof null". The two biggest are (a) not having the "window" object be the global scope (there are many possible designs for the global scope, but "window" is not part of any of them), and (b) the semantics of nested function declarations (which are currently not in the spec, implemented in multiple browsers, with a "portable" intersection that no one likes).
What's the deployment plan for a new language like DART? New mime type not text/javascript? Is there any difference between handling a new language and an (incompatible) version of an old language?
+Anne van Kesteren wrote above: "+David Baron wrote and (restatement of the first). I do not think he got around to writing part 2."

Yeah, I never did. I have an outline of part 2, but it never seemed urgent to write: it was about the fiction (and resulting problems) of cross-layer version dependencies: i.e., the idea that various specs claim to be built on top of a particular version of some spec in a lower level of the stack, how that doesn't match the reality of implementations, and the problems that would occur if things actually did work that way.

Maybe one of these years I'll clear out my "to blog" file.
+David Baron that would be a really useful blog post to have. People seem to love referencing outdated and often inaccurate versions of lower-in-the-stack specs for Process reasons without regard to the issues it causes.
I would highly recommend a spec-like doc that can be updated and refined. I guarantee that there will be holes in reasoning that will need to be patched up.
Anyone have an example or two of a spec that claims to be built on top of a particular (or outdated and inaccurate) version of lower-in-the-stack? Usually the rule with updates to referenced versions is "use at your own risk" because the interaction between the spec making the reference and (potential) update.
+Larry Masinter So back when SVG 1.1 first edition was the latest, and XML 1.1 was new, I believe I'd heard SVG WG members claim that the fact that SVG 1.1 referenced XML 1.0 meant that it wasn't possible to use XML 1.1 with SVG, though I don't recall if they actually claimed that implementations must reject such a document. I think the presence of beliefs like this contributed to the lack of uptake XML 1.1.

Another example I had was references from IDN specs to particular version of Unicode (not sure if that's still the case), such that IDN required characters assigned in newer versions of Unicode to behave badly.

I think there's also something to be said about IRI vs. URI, though I think that case is a bit more complicated.
SVG referencing CSS2 (vs "CSS") was the source of much drama too.
New proposal:

Versioning happens, ES1 < ES2 < ES3 < ES5 but not < ES5 strict -- runtime semantic changes due to strict mode mean you have to test two ways. This was unfortunate, we don't want to do it again. New syntax as the opt-in expression saves us.

RFC 4329 versioning is still useful to hide scripts from old browsers that will choke on them. We do not have a forward compatibility story. Hixie and Maciej suggested one in 2007 (IIRC) but it failed to cope with regular expression (future-proofing of, actually) and I believe ASI. As dherman says we will get there, but not quickly enough for ES6.

Everyone happy now? Happy new year!

Happy new year +Brendan Eich , I think that using the module syntax as the opt-in sounds great! (Was it just me, or was there no notification for Brendan's comment?)
Add a comment...