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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
