The 1JS experiment has failed. Let's return to plan A.
Mark S. Miller
erights at google.com
Wed Dec 26 15:26:28 PST 2012
On Wed, Dec 26, 2012 at 2:58 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Mark, you cite some issues we need to work through, but opt-in via pragma
> syntax beyond "use strict" is not one of them.
Sorry for the confusion. As I just clarified in my response to Dave, I
am not suggesting any of those previous MIME type or additional pragma
ideas. I am just suggesting that we stop twisting the language to try
to fit ES6 features into non-strict mode when these don't fit well.
> What's more, the big-picture claim in your Subject line ("has failed"
> especially) is not true. In an overriding sense, 1JS can't fail, because
> versioning is an anti-pattern (or at best retrospective, not prescriptive)
> on the web. To be more precise, ES6 will fail if it requires opt-in
> versioning apart from the new syntax itself.
I am not suggesting any new opt-in beyond what we've already got. I am
suggesting that we use that opt-in, rather than contort the language
for the sake of non-strict mode. We all know that the non-strict mode
said about the arguments object, let's stop polishing this turd.
> This applies to "use strict"
> too, since it has costs (both performance and semantic changes that double
> testing while old browsers are in the field).
I thought we'd settled the performance issue. I'm surprised you're
still raising it.
The purpose of testing is to alert you to places in your code where
bugs may reside. Even if you never plan to run your code in strict
mode, you should still test in strict mode, since anything that fails
in strict mode is likely enough a bug in your code that you should
> Now, on the specific JSC bug you cite,
> https://bugs.webkit.org/show_bug.cgi?id=27226. This is actually from 2009,
> filed based on a misunderstanding of ES3 and not on any real-world web
> content, and finally marked invalid in February. It is old news. The
> comments from February do not prove that "[t]he 1JS experiment has failed".
I was unaware of the history, thanks. I withdraw that bullet point. I
acknowledge that my case is substantially weaker without it.
> And JSC design decisions are not authoritative over TC39 as a whole --
> rather, the reverse!.
We all know that this issue isn't so unidirectional. If TC39 mandates
something and the browser makers decide to do something else, we all
have a problem. The pressure to avoid these problems cuts both ways.
> Anyway, we can certainly make function-in-block ES6 semantics require "use
> strict" opt-in, but that will both diminish the use-frequency of
> function-in-block with sane and standard semantics,
Since only strict mode provides sane and standard semantics anyway... ;)
> and as Andy Wingo
> pointed out in the JSC bug, confuse users with two semantics for the same
We've already got that. To avoid confusion, "use strict".
> More in reply to Brian Terlson's thread.
More information about the es-discuss