ModuleImport

Kevin Smith zenparsing at gmail.com
Tue Jul 1 10:10:32 PDT 2014


There are three arguments for default exports:

1.  Anonymous exports are a value-adding feature, as it allows the user to
use a library without having to know the export name.
2.  Default exports allow more streamlined renaming of the imported binding.
3.  Default exports allow smoother interoperability with legacy modules.

The responses to these arguments are:

1.  It's not clear that anonymous APIs add value, since the user of an API
always has to refer to it's documentation, and therefore will always be
exposed to its exported API names.
2.  From experience with other languages like Python, we know that import
renaming is the exception rather than the rule.  As such, streamlined
renaming only results in a marginal benefit.
3.  Interoperability with legacy modules is possible by using a simple
naming convention.  Default exports would improve the user experience of
importing from legacy modules somewhat, but optimizing legacy modules
should not be a primary motivating factor in the design.

And

4.  The default export feature is confusing to users, because it gives the
appearance of module-object-overwriting (in the Node sense) while acting
completely different on a semantic level.  Syntactically, the design favors
default exports while semantically it favors named exports.  Since the
module system is the entry point to the language for users of all
experience levels, the module system should not be confusing.  It should be
as simple and obvious as possible.

Given that the costs (4) do not outweigh the benefits (1, 2, 3), default
exports should be dropped.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140701/c1a84912/attachment.html>


More information about the es-discuss mailing list