A few more questions about the current module proposal

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Wed Jul 4 11:56:46 PDT 2012

On Wed, Jul 4, 2012 at 9:13 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:

> On Wed, Jul 4, 2012 at 12:29 PM, Jussi Kalliokoski
> <jussi.kalliokoski at gmail.com> wrote:
> > Hello, good people,
> >
> > I fear I have some misunderstanding going on with the current module
> > proposal, as well as outright ignorance, hence I'd like to get answers
> to a
> > few questions, as I'm pretty sure I'm not the only one. :)
> >
> > 1) How does the static resolution and static scoping behave when out of
> the
> > normal context. As an example if `import` is in an `eval()` call, what
> would
> > happen:
> >
> > var code = loadFromURL('http://example.org/foo.js') // content: `import
> foo
> > from "bar"`
> > eval(code)
> > console.log(foo) // ???
> First, what does `loadFromURL` do?  That looks like sync IO to me.

Indeed it is, to simplify things. Let's pretend it's a function that gets
the text contents of a URL.

> > Would this example block until the module is resolved and loaded? Would
> it
> > throw? What happens, exactly? As my $0.02 goes, I think it's a bad idea
> to
> > ban import in eval.
> Second, it depends on whether "bar" is a previously-loaded module.
> For example, if "bar" is a library provided by the host environment,
> such as the browser, then everything will be fine, and the code will
> import `foo` successfully.  If "bar" is a remote resource, this will
> throw -- we're not going to add synchronous IO to `eval` (or to
> anything else).

So basically, eval()'ing something acquired via XHR would no longer give
the same result as it does if the same script is in a script tag? Suffice
to say I disagree strongly with this choice, but I'm sure the rationale
behind this choice is strong.

> > 2) How does the module proposal address the increasing need for
> interaction
> > between pure JS and compile-to-JS languages? (CoffeeScript, Haxe, JS++,
> JS*,
> > etc)?
> >
> > More specifically, can you add hooks to preprocessing the files? If not,
> > why? I think it would break static module resolution, but are we certain
> > that static module resolution is worth the price of excluding JS
> > preprocessors of the module system (aside from server-side preprocessing
> > that is)? Again, my personal opinion is that including compile-to-JS
> > languages in the module system would be worth much more than static
> > resolution, but feel free to enlighten me.
> We've thought a lot about compile-to-JS languages, and a bunch of the
> features of the module loader system are there specifically to support
> these languages.  You can build a loader that uses the `translate`
> hook to perform arbitrary translation, such as running the
> CoffeeScript compiler, before actually executing the code.  So you'll
> be able to write something like this:
> let CL = new CoffeeScriptLoader();
> CL.load("code/something.coffee", function(m) { ... });
> There are two ways to potentially make this more convenient.  One
> would be to add something to HTML to declare the loader to be used
> with particular script tags, which we've talked about, but I think we
> should wait on until we have the base module system in place.  The
> other would be to ship some of these loaders in browsers, but if I was
> the author of a compile-to-JS language, I wouldn't want to be chained
> to browser release and upgrade schedules.

Okay, seems like it's a solution of a sort. Next question is that does this
mean that for example CoffeeScript programs will be able to use pure JS
modules using the import statement? i.e. can the translated code contain an
import statement? If yes, as I presume, good.

Still, this is nowhere near the convenience of node's require() and the
possibility of adding a new preprocessor just using
require.registerExtension() and after that you have the same require() for
a new language. I guess we'll see whether that convenience will outweigh
the benefits of static resolution.

And btw, please don't mistake my concern for negativity, I really
appreciate the extremely hard work behind the current proposal; but I'd
hate to see it not ending up superior to the existing module systems (i.e.
making them useless), becoming just another module system library authors
have to support and for which to provide different versions, as well as
just another module system developers need to know how to use because a
third-party module they use works only with it. That fragmentation cost
would imho be far worse than not having a standardized modules at all (for
now), but I guess we'll find out whether it's a hit or a miss only after
it's already there.

Thanks for answering my questions!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120704/61b245b7/attachment.html>

More information about the es-discuss mailing list