ES Modules: suggestions for improvement

[Brendan Eich]

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.

> 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?

> Import checking can still be added afterward.

How?

/be