A few more questions about the current module proposal

Sam Tobin-Hochstadt samth at ccs.neu.edu
Thu Jul 5 10:59:36 PDT 2012


On Wed, Jul 4, 2012 at 2:56 PM, Jussi Kalliokoski
<jussi.kalliokoski at gmail.com> wrote:
>> > 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.

There's a `Loader.evalAsync(src, cb)` method which supports fetching
remote resources using `import` statements.

The alternatives would be one of:
 - banning reference to remote data except using callbacks
 - making `eval` do synchronous IO

I think both of those are much worse.

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

Yes, translation is to the full JS language.  Of course,
CoffeeScript's interface to the JS module system is up to Jeremy, not
Dave and me, to decide.

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

There's no tension between static resolution and allowing the loader
to change dynamically -- I've posted lots of code using `System.set`,
for example.  Making the default system loader arbitrarily mutable has
many other potential problems, though: it makes it harder for engine
implementers to optimize, it potentially raises security holes, it
lets any code on the page change the meaning of all the rest of the
code on the page.  But fundamentally, that's about the design of the
System loader, and we can improve that without having to change the
fundamental aspects of the design (that's one of the nice aspects of
the system).
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list