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