Modules: Curly Free

Kevin Smith zenparsing at
Sat Apr 20 20:19:24 PDT 2013

> I don't really know how to answer opinions like this. It just seems
> like... it's fine that you feel that way, but kind of irrelevant.
> Significant communities of JS developers have already spoken -- in words
> and in precedent -- that they disagree with you. So for both smoother
> interoperability and continuing to support what is a highly valued use
> case, it's a tiny price to pay.
Well, first, I've said before that I'm on the fence on "anonymous" exports.
 There are more important things at play, and I don't want to get stuck in
any land war over it.  But to argue the other side for a moment:

- Supporting anonymous exports makes the model a little more complicated.
 We can quantify that with number of productions, or lines of pseudo-code,
or whatever you like, but that's a fact.  All else being equal, simple is

- I don't believe you've really made the case for how anonymous exports
will make things better.  It's not enough to say that "developers really
want it".  There has to be a convincing technical argument.  I'm not ruling
it out, I just haven't seen it yet.

Look, I was there on CommonJS arguing for "exports overwriting".  I
identified that use case years ago.  It didn't just spring forth as
*wisdom* from some JS collective mind.  It was entirely motivated by the
"remote function call" model of modules in CommonJS (and it's fork, AMD).
 Basically, this is an nasty, ugly pain to write:

    var MyAbstraction = require("./MyAbstraction").MyAbstraction;

Not because you have to name MyAbstraction, but because you have to intone
it *three* times just to pull out the reference.  Let's compare that to
what you might write with ES modules:

    import MyAbstraction from "MyAbstraction.js";

Beautiful!  The use case evaporates, does it not?  OK, but what about

    import MyAbstraction as Whatever from "MyAbstraction.js";

Still beautiful.  You're going to have a hard time arguing that renaming is
such an awful user experience here.

And on the provider side, I stand by my claim that requiring an author to
actually *name* an abstract concept is entirely reasonable.

Next, what about interoperability with legacy modules?  Well, we need to
see an end-to-end demonstration of how that's actually going to work in
practice before we admit it as a technical argument in favor of anonymous
exports.  I've tried to demonstrate in the past that I don't think it's
going to work out, but I'd be happy to be proven wrong.

Dave, I *know* that you've gotten more than your share of flame for the
past two or three years on JS modules.  But anyone that directs flame your
way needs to put up a technical argument, here on es-discuss, or shut up.
 You can tell them @zenparsing said so.  : )

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list