Default exports, without explicit syntactic support

[Calvin Metcalf]

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;`


On Thu, Jun 26, 2014 at 9:39 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>
> (I’m happy with David’s proposal, but I’d like to try bikeshedding one
>> more time.)
>>
>
> For my part, I no longer think that the "import * as foo" change solves
> anything.  The underlying problem is default exports - it's just plain
> confusing to users.
>
> // main.js
>> import { _ as MyClass } from "lib/MyClass";
>> ```
>>
>
> A similar idea was proposed by Andreas Rossberg last year, but it was shot
> down at the time.  And honestly, I just don't think even a convention is
> necessary.
>
> (This is going to be a bit long - bear with me.)
>
> Let's take a step back for a second.  The "export overriding" thing (i.e.
> module.exports = ?) was never a part of the CommonJS spec.  So why did that
> pattern take off in Node?
>
> Let's go back to CommonJS.  If you had a module which just exported a
> single thing (which is obviously very common), then what would that look
> like?  First let's look at the export side:
>
>     // my-class.js
>     exports.MyClass = function() {
>         // initialize
>     };
>
>     exports.MyClass.prototype.method = function() { ... };
>
> Now the import side:
>
>     // use-class.js
>     var MyClass = require("./my-class.js").MyClass;
>
> Notice how we have to invoke three names on the import side:  one for the
> variable name,  one for the module name, and one for the exported name.
>  This is an *awful* user experience.  Now let's rewrite the same thing
> using "module.exports":
>
>     // my-class.js
>     function MyClass() { ... }
>     MyClass.prototype.method = function() { ... };
>     module.exports = MyClass;
>
>     // use-class.js
>     var MyClass = require("./my-class.js");
>
> Ah - a much better user experience, right?
>
> So do we need to mimic the same "export overwriting" in ES modules?  Let's
> see:
>
>     // my-class.js
>     export class MyClass {
>         constructor() { ... }
>         method() { ... }
>     }
>
>     // use-class.js
>     import { MyClass } from "my-class.js";
>
> What do you think?  Is there any user experience issue here that needs to
> be sugared over?
>
> Notice that, on the import side, *exports overriding in Node is an
> equivalent user experience to normal importing in ES modules*.
>
> Therefore, my conclusion is that syntactic support for "default exports"
> does not provide any measurable improvement in user experience.  On the
> other hand, default exports is clearly confusing to users.  The balance
> seems clear to me:  default exports needs to be dropped from the design.
>
> Feedback?  Counter-arguments?
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
-Calvin W. Metcalf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140626/b63aa76a/attachment.html>