Default exports, without explicit syntactic support

Kevin Smith zenparsing at
Thu Jun 26 07:06:22 PDT 2014

On Thu, Jun 26, 2014 at 9:56 AM, Calvin Metcalf <calvin.metcalf at>

> the slight difference in `import { MyClass } from "my-class.js";`
> compared to `var MyClass = require("./my-class.js");` is that in cjs
> MyClass is a variable the user create, meaning the user only need to know
> about 1 name from the remote module, the path, but in ES6 MyClass is set by
> the exporter meaning similar to ` var MyClass = require("./my-class.js").MyClass;`
> I need to know both what the path is it's coming from and what the hell
> they named the export.  In the case of a collision or just a badly named
> module you would be doing `import { really_poorly_named_class_factory_bean
> as MyClass } from "my-class.js";` which is cognitively similar to ` var
> MyClass = require("./my-class.js").MyClass;`

Ah, right - thanks for mentioning this!

First - I reject the idea that making the export "anonymous" is in any way
good practice.  Frankly, naming things is essential to API design.

But default exports do give us a UX gain when we want to rename the import.
 The question is:  is this a marginal gain, or an essential gain?

In my experience, I rarely need to rename an import:  the ratio might be
10:1, at best.  So my experience suggests that it's a marginal gain.  Other
experiences would be helpful.

If it's only a marginal gain, then I don't see how it can offset the
confusion that default exports are causing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list