Rationale for dropping ModuleImport syntax?

[Kevin Smith]

"esparse" used to have a module which exported a huge list of things, and
for the same reason I believe.

Basically there's an "AST" module which exports a huge list of AST
node-type classes.  That module is then exported to the public interface.

https://github.com/zenparsing/esparse/blob/53566066a9d1780bb27f73d208160595e2e0bb47/src/AST.js

I moved away from this approach only for performance reasons (basically to
avoid inheritance) because I'm optimizing hot, transpiled ES6 -to-ES5 code.
 Were it not for the (somewhat ugly) performance optimization, I would have
left the multi-export design.



On Mon, Jun 9, 2014 at 11:41 AM, Erik Arvidsson <erik.arvidsson at gmail.com>
wrote:

> Traceur definitely has a lot of exports in a single module.
>
>
> https://github.com/google/traceur-compiler/blob/master/src/syntax/Parser.js#L15
>
> We do not however, use the `module` form since we want to get rid of the
> extra Get (which deopts switch statements in some engines).
>
> On Mon Jun 09 2014 at 11:36:58 AM, Caridy Patino <caridy at gmail.com> wrote:
>
>> My perspective here is that there are not too many modules (in nodejs)
>> that rely on more than a handful of exports from a particular module, we
>> are actively working on validating this using esprima in a large set of npm
>> modules. If this is true, we should be just fine with specific imports, and
>> for the edge cases, an imperative form should be sufficient.
>>
>> For now, I will ask you all to try to find a modules that are using too
>> many exported methods from one of its imported modules, you will be suprise
>> how hard it is too find those.
>>
>>
>> /caridy
>>
>>
>> On Mon, Jun 9, 2014 at 11:27 AM, Axel Rauschmayer <axel at rauschma.de>
>> wrote:
>>
>>> As an aside, it is yet to be seen whether the "default" export thing is
>>> the best way, or the bad part itself.  We don't have the real world
>>> experience yet to answer that.
>>>
>>>
>>> I’d even argue that they led to the predicament that we are currently in.
>>>
>>> If the default export didn’t look like “the module”, things would, in my
>>> opinion, be easier to understand:
>>>
>>> ```js
>>> import _ from "Underscore";
>>> import { flatten, union } from "Underscore";
>>> import default someFunction from "single_function_module";
>>> ```
>>>
>>>  --
>>> Dr. Axel Rauschmayer
>>> axel at rauschma.de
>>> rauschma.de
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140609/242d81a9/attachment-0001.html>