ModuleImport

Matthew Robb matthewwrobb at gmail.com
Sat Jun 28 10:55:26 PDT 2014


What if the Loader spec had some attention given to match AMD/CommonJS for
some cases and leave the new syntax for the new module semantics. Really
what we want is for non-es6 module systems to be able to hook into the
loader registry in a way that makes sense for them and will also make sense
for IMPORTING those modules into es6 modules. require/define work in
browsers and in node TODAY, the conversation imo shouldn't be about giving
those systems better syntax it should be about creating a single
registry/loader that easily supports all paths.


- Matthew Robb


On Sat, Jun 28, 2014 at 9:48 AM, John Barton <johnjbarton at google.com> wrote:

>
>
>
> On Sat, Jun 28, 2014 at 9:03 AM, Kevin Smith <zenparsing at gmail.com> wrote:
>
>>
>>> Static checking on exported members feels odd.
>>>
>>
>> Static checking of imports and exports has well-known advantages and
>> would help the long-term viability of the language.
>>
>
>  Enumerating these specific advantages would inform this discussion.
>  These advantages are not well-known. Many developers have experienced the
> disadvantages of complex systems of rules and thus favor simple solutions
> over ones with theoretical advantages. Explaining the benefits concretely
> would help them balance the well-known costs.
>
> jjb
>
> _______________________________________________
> 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/20140628/c2d09a2d/attachment.html>


More information about the es-discuss mailing list