Minor questions on new module BNF

James Burke jrburke at gmail.com
Tue Jun 4 09:55:32 PDT 2013

On Tue, Jun 4, 2013 at 8:02 AM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
> From: Yehuda Katz [wycats at gmail.com]
>> In general, expectations about side-effects that happen during module loading are really edge-cases. I would go as far as to say that modules that produce side effects during initial execution are "doing it wrong", and are likely to produce sadness.
>> In this case, the `import` statement is just asking the module loader to download "someModule", but allowing the app to move on with life and not bother executing it. This would allow an app to depend on a bunch of top-level modules that got executed only once the user entered a particular area, saving on initial boot time.
> I don't think this is correct. It is strongly counter to current practice, at the very least, and I offered some examples up-thread which I thought were pretty compelling in showing how such side-effecting code is fairly widely used today.
> This isn't a terribly important thing, to be sure. But IMO it will be very surprising if
> ```js
> import x from "x";
> ```
> executes the module "x", producing side effects, but
> ```js
> import "x";
> ```
> does not. It's surprising precisely because it's in that second case that side effects are desired, whereas I'd agree that for modules whose purpose is to export things producing side effects is "doing it wrong."

Agreed, and this is at least what is expected in AMD code today. Not
all scripts export something, but are still part of a dependency
relationship (may be event listeners/emitters). The `import "x"`
expresses that relationship.

I do like the idea of module bodies not being executed (or even
parsed?) if it is not part of an explicit System.load or import chain.
For code that wanted to delay the execution of some modules though, I
expect that trick to be worked out via a delayed System.load() call
than something to do with an import "x" combined with a System.get().

This is how it works in AMD today: define()'d modules are not executed
until part of a require chain. Some folks use this to deliver
define()'d modules in a bundle, but only trigger their execution on
some later runtime event, and then do a require(["x"]) call (which is
like System.load) that would then execute the define()'d "x" module.

So: yes to delayed execution (and even delayed parse), but not via
import "x" + System.get(), just via System.load(), and all import
forms doing the same thing for module body execution.


More information about the es-discuss mailing list