ES Modules: suggestions for improvement

[David Bruant]

As a starter, I'd like to say that jQuery may not be the best example
since it's heavily maintained and it's certainly an exception by
comparison to the massive amount of JavaScript library out there.
Also, jquery seems to attach its properties to the 'window' alias rather
than the top-level 'this'. I'm shooting myself in the foot here, but
it's worth noting that it would be an easy change (like a couple of
characters) to make jQuery as usable today and potentially directly
compatible with the ES module syntax.

Le 27/06/2012 11:48, Brendan Eich a écrit :
> David Bruant wrote:
>> Import checking is definitely a feature that's worth it, but Isaacs
>> idea to being able to import jQuery (or any library of course) as is
>> by having the module global scope into the "export object" without
>> polluting the actual global object seems to is definitely a win.
>
> That's maybe a win, but we don't use JQuery that way today.
> Speculating about future usability is perilous. We'd need to implement
> and test, but see below for some questions to answer first.
>
> If it's important, then people can build such a system using loaders.
> But it's at this point completely undemonstrated that exposing
> JQuery's few top-level bindings in an imported object beats (for
> usability, simplifying old vs. new clients, or any other measure)
> modifying JQuery to export those bindings and then importing what the
> client uses.
Old clients don't need to change anything. They're neither simplifyed
nor complexified. It makes new client simplified in the sense that they
don't need to work on the library to make it ECMAScript module compliant.

>> Being able to import existing libraries as modules without changing a
>> bit of the library, without even having to read it or worry about
>> global leaks is a strong win in my opinion. It's worth not having the
>> typo check for this particular case.
>
> Either way, there's a different client code obligation from today's
> pattern.
>
> It's true you can use today's JQuery as is, but why would you use a
> new client API or syntax and require only new browsers or else
> trans-compilation? What's the benefit?
The benefit is only that libraries would be compatible with the new
'import' syntax without a change. Current clients wouldn't have to
change anything. ES6 clients could use the new "import" syntax.

>> Import checking can still be added afterward.
> How?
By "afterward", I meant "by changing the library afterward". This would
be done by tracking down things that are exported and using the proper
syntax to replace them.
But the point is that once a client has written

    import jQuery from "./jQuery.js"

then, whether the module has explicitely exported or not, you're good to
go. If later 'jQuery.js' has turned its top-level binding into 'export'
statements, client code doesn't need to change. It acts exactly the same
way.
I realize I was wrong, import/export matching can still happen even
without 'export' statements. It just happens later. Without export
statement, import/export matching requires to evaluate the code, while
with 'export' statement, it can be done at parse-time.


I'd like to take a different perspective on that topic.

    import x from './x.js'

At the very least, this statement will trigger the download of x.js and
parsing of it. If the parsing is successful, then there are 2 cases:
either the code has 'export' statements and that's what will be
imported. Or the code has no 'export' statement. Then what happens?
One solution could be to say that 'x' is not in the exports (since there
is none) and throw an error. Or, it could be considered that this
library exposes its exports in its top-level binding. The latter idea
would turn all existing and
future-until-ECMAScript-modules-are-mainstream JavaScript libraries into
modules for free, because exposing global properties is what JavaScript
programmers have been doing while waiting for a proper module system
(until recently with CommonJS, AMD, etc.)

The downsides are weaker checking (no 'export' statement turns into
'your top-level binding is an implicit export area') and later import vs
export name checking. It sounds like a decent trade-off to leverage all
existing code.

David