excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Sun Dec 30 22:46:54 PST 2012

Kevin Smith wrote:
> This is a bit long - bear with me...
> First, let me make one more argument as to why "new syntax, just use 
> it" won't work:
> (a) In ES6, "let" is the preferred way to declare variables.  Let's 
> not be relativistic to the point of goo here.  Block-scoped variables 
> are "better".  As such, "let" is of central importance to the language.
> (b) ES6 sloppy mode cannot have "let".

That's overstated, and as such it contradicts the tenuous consensus of 
the last TC39 meeting: to reserve 'let' contextually in sloppy mode and 
evangelize any let [x] = y code out there already (which we've yet to 
find -- 'let' is used as an identifier, short for 'letter', but not 
indexed into on LHS).

The rest of your reasoning is therefore overstated. It does not follow 
if we can reserve 'let' in ES6, mode-free.

> (c) Therefore, ES6 sloppy mode is a hobbled, incomplete version of the 
> ES6 language, and

See above.

> (d) Since ES6 sloppy mode is not the same as ES6, there can be no 
> "1JS" as long as ES6 sloppy mode exists.

Here I want to refine my Platonic prettiness critique. You talk about 
ES6 as if it can be a thing, which has a timeless existence and truth 
and beauty. Kind of like a dodecahedron -- a pure "Math thing".

I see that, but it's an abstraction. It is not real, it is ideal. In 
reality, you might argue the spec approximates this thing, but there are 
many problems.

What I think "exists": ES6 as a practical language with a large user 
community who apprehend it in pieces, and sometimes using different 
metaphors or incomplete and even inconsistent "theories" or schools of 
thought. It's a human thing, not a Math thing.

In this light, "1JS" is totally winning. It's a "true myth" as much, or 
moreso in my view, as the "use strict and you'll lose the crazy" true-myth.

> Sure, you could attack (b) by using parsing tricks and special cases.

We agreed at the last meeting to treat 'let' as a contextual keyword at 
start of statement if followed by an Identifier, '{' or '['. That is a 
special case, but so what? 'module' was not reserved in ES1-5 so it 
needs a special case too.

The spec must serve the users. Not the other way around. Or would you 
give up 'module' from sloppy mode?

>  You can make anything "work".  But then we're shirking the language 
> designer's responsibility of guarding the values of simplicity and 
> elegance.

These matter a lot but they are rather less well-defined than you make 
out here. I think 1JS is simple and elegant, even with other new syntax 
than 'module' as its own opt-in. I think I can make that case, and I'm 
trying to.

But to continue my point above, the simplicity and elegance, subjective 
in many ways, of the "ideal" ES6 must take a back seat to the real ES6, 
including its ease of adoption. That's where I think requiring "use 
strict"; to use new syntax (other than 'module') hurts more than it helps.

Imagine you are adapting existing code, including popular libraries not 
yet in strict mode, to a new app targeting ES6 or better runtimes 
directly, and ES5 and older via a compiler such as 
https://github.com/matthewrobb/six. You are not yet be ready to "use 
strict" in the concatenation of all the code -- there's too much risk of 
breaking something, and never enough test coverage.

You want to use ES6 features such as rest parameters and destructuring 
right away, before any "use strict" or module wrapping. Under your 
proposal, you can't. You have to multiply risks and spend time turning 
on strict mode, testing harder in old and new and middling (IE9, 
anyone?) browsers.

Why is this a good thing?

Oh sure, in 10 years, no worries. But let's consider that future, which 
Andreas and others argue is larger than the past.

In 10 years, you want everyone to use modules, but there'll still be 
top-level code, rapid prototyping, and so on. For such programs, you 
want everyone to write the old

"use strict";

chestnut, about which StackOverflow misadvises now (and probably will 
then :-P) that minifiers can safely remove this "comment"?

Where's the ideal truth and beauty in this 
useless-string-expression-statement-as-pragma hack?

> I take it that you agree in principle with strict mode.  If I 
> understand correctly, your central argument against "1JS under strict" 
> is that:
> (a) Strict mode is not popular.

No, I said it's not widely adopted and I've chosen my words carefully. 
Re-read my last few messages. It will take time to win everyone over, 
and even then the Law of Least Effort says it will be left out now and 
then, forever. Nothing on track for Harmony will insist on it as a 
shibboleth that must be uttered in some future, say ES8.

So it will be left out, and not every program is a module.

I really don't think I've been unclear about this. In particular I don't 
think I used popularity as some kind of static construct, ever. I've 
argued about slow (many years) adoption, which is an empirical fact. 
I've argued based on the design of the pseudo-pragma itself, that it 
tends to be left out. I've therefore argued against multiplying risks. 
That's it.

> (b) If ES6 syntax is strict-only, then ES6 may well be unpopular.

Not quite. This is where I think a reductio ad absurdum has been put in 
my mouth. I never wrote that people will say "ES6, yay! Wait, I have to 
hassle with strict mode enabling?" and ES6 will suffer. That's too simple.

Yes, some people will bitch. They are probably mostly the same folks who 
will not want ES6 anyway, but a few would be open to what I propose: new 
syntax as its own opt-in (and with strict bodies, where there are code 
bodies). But let's leave them aside for a minute.

The problem I see is rather the permanent requirement for the "use 
strict"; shibboleth, and the ritual spanking one will get when 
forgetting to utter it up front before using any ES6 feature, however 
lovely and useful in a legacy or mixed codebase.

Again, why?

To preserve some idea based on your economics for simplicity and 
elegance but not mine? We could perhaps try to unify how we count these 
goods. But I think we should first try to get on the same real, 
as-used-in-practice, developer-facing terrain I'm arguing trumps 
whatever Platonic ideal we might (and probably do) share.

> So why is strict mode not popular?  The answer is quite simple: 
>  there's no carrot.  It limits the user (in good ways, of course) 
> without providing any additional power to offset those limitations. 
>  ES6, built exclusively on top of strict mode, provides those missing 
> carrots.

There's no carrot and there are a few sticks, which are going away but 
not yet gone (performance faults, concatenation hazards, downrev 
browsers up to IE9 still in the field). Don't forget the sticks in the 
"short run".

But even in the longer run, with no sticks, ask yourself: "why am I 
requiring all users of new post-ES5 syntax, which could be a lot (future 
larger than past) to utter some silly string constant expression 
statement to use the new syntax, except for 'module', maybe?"

I see no simplicity and less elegance in making such a permanet 
requirement for "use strict".

If we want more strict code sooner, let's make all the new 
code-body-bearing syntax in ES6 strict by fiat.

> If that's the case, then why are some users vehemently anti-strict?

Opinions vary on all sorts of things. Your argument here is off target. 
*My* argumet is not about popularity or fickle developers. It is about 
the cost of "use strict" in itself, and its risks gratuitously 
multiplying to reduce the odds of good ES6 adoption experience and 
long-run ES6, ES7, ES8, and (I hope not) ES9 truth and beauty.

In other words, I'm arguing about better design, both in terms of 
intrinsic expressiveness and in terms of human factors. I don't think 
"use strict" is expressive or usable in the large, or at least not any 
more so than 'module' wrapping or (my position) 'class' or other body 
form (generators, arrows) wrapping.

Pseudo-pragma vs. new syntax with strict-by-definition body -- this is a 
no-brainer for me. But I don't have a particular "use strict"; adoption 
axe to grind. I want more strict code, sooner, with less ugly 
boilerplate and potential for painful adoption.

>  As you've stated, javascript is a big tent with many loud voices 
> inside.  It doesn't matter *how* the language evolves, there are going 
> to be users on soapboxes proclaiming that "standards bodies suck" or 
> shouting other blustery provocations.  Change always creates winners 
> and losers.  But the language must evolve nevertheless.

Nothing here is at issue, this is off target. Let's get back to the 
design issue.

> What would convince you that strict-mode would not present a problem 
> for ES6 adoption, if ES6 syntax were strict-only?
Obviously, if "use strict" were much more rapidly adopted, not 
necessarily majority by large-survey counts (github, web crawls) but 
trending up toward that end in a way that would be hard to reverse.

Other than that, you have to go back and actually engage my arguments. I 
do not have as an axiom that strict-mode opt-in via "use strict" is a 
good in itself. It is a means to an end. There are other means, 
apparently we even agree on one ('module' wrapping).


More information about the es-discuss mailing list