excluding features from sloppy mode

Kevin Smith khs4473 at gmail.com
Fri Dec 28 15:12:26 PST 2012


> The question really is, why have sloppy-mode classes at all? Who wants or
> needs them?
>

Well, no one, really.  But we shouldn't want big invisible switches or any
new pragma-haunts either.

You've said that my predictions are "wildly optimistic", and I'm going to
have to push back.

Let me, like the Ghost of Christmas Present, take you on a tour of the
current state of the art in *interoperable* javascript modules, on this eve
of 2013.

Behold, UMD (Universal Module Definition), the "jewel" of the javascript
community:

https://gist.github.com/4402566

Everyone, and I mean *ev-er-y-one*, will be ecstatic when this scourge is
beaten, burned, scattered, and wiped off the face of the Earth.  Sure,
Scrooges everywhere will say "Bah humbug!  ES6 modules suck!", but it's
laugh-out-loud ridiculous to think that anyone, anywhere would choose UMD
over ES6 modules.

A standardized module syntax is the #1 needed feature in javascript, bar
none.  We don't need to worry about adoption.

Well, what about Node and NPM?  There's a well-established module system in
place which has some apparent incompatibilities with ES6 modules.  What to
do?  Well, Node will move in the direction that it *has* to move: toward
ES6 modules.  Championing a legacy module system with well-known problems
in the face of ES6 modules, as standardized by EcmaScript, is a
non-starter.  And ultimately, despite the gnashing of teeth over on
Twitter, this will be a good thing for javascript users.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121228/f2a7d5ae/attachment.html>


More information about the es-discuss mailing list