excluding features from sloppy mode

Brendan Eich brendan at mozilla.com
Sun Dec 30 15:33:43 PST 2012

Claus Reinke wrote:
> // suggestion
> Perhaps there is a way to make the automated upgrade
> problem solvable/cheap? Instead of ES6+ supporting sloppy
> mode and strict mode and mixtures of new features with
> sloppy mode indefinetly, how about turning the situation
> on its head:
> - ES6 engines default to strict mode, with new features
>    (the cleaner future)
> - ES6 engines support a "use ES5" pragma
>    that switches off both new features and strict mode
>    (give a helping hand to support old code)
> - ES6 engines ignore "use strict"
> - ES3/5 engines ignore "use ES5"
> // end suggestion
> That way, you don't have to version to use new language
> (the current standard), only to use old language. And all
> code owners have to do to support unmaintained code
> is to slap "use ES5" in front of it - easily automated. 

Sorry, this is deeply unrealistic.

Easily automated by whom? Who does all the non-automated work testing 
and deploying? Of unowned content hosted by companies paying the bill 
for the hosting but not for any maintenance or changes?

You're talking about the entire web, billions of pages at this point. 
Scripts are at least as common as pages going by MIME type requests:


(look for "Most common mime types").

Your suggestion also doesn't work without perfect, up front conversion. 
Any laggard web content of size, and browser game theory kicks in. First 
browser to do as you propose "breaks (a sizeable part of) the web" for 
its users and loses market share.

The web used to be indexable in a coherent sample but its size outgrew 
that limit long ago. If search engines can't coherent index, there's no 
way we'll get "tooth-full" (that is, enforced by all browsers in a 
sea-change event) ES6-strict-only enforcement unless the script has "use 
ES5". We won't get "use ES5" where needed, and no browser vendor will 
take the chance.

A closing thought: you may want ES5 strict to be the basis of all future 
code, but it has not yet been widely adopted. It should be and may be, 
but time will tell. Best to work to increase the quantity of strict-mode 
code on the web over time.

That's why I keep advocating making all new ES6 syntax-forms with code 
bodies strict by fiat.

Andreas, Mark et al. want new syntax only under strict mode (implicitly 
in module, mostly -- I have to keep asking!). That works too, except for 
the overhead of opting into strict mode, which is easy to forget to do.

In no case does breaking the web (really, breaking any browser foolish 
enough to try) work.


More information about the es-discuss mailing list