Static Module Resolution

Brendan Eich brendan at
Sun Jul 1 10:12:52 PDT 2012

Kevin Smith wrote:
> Like just using good-ol' require instead of import?  : )

Not in the browser. Again, for like the umpteenth time, without a 
pre-processor, require is not equivalent to import. You have to put the 
continuation in a callback passed to require.

If your point is that given downrev browsers, web developers will use 
only one method, that's not clear:

1. Use require taking a callback. This is not popular, as Isaac said, 
Node.js ran screaming from it to synchronous require because of its lack 
of usability.

2. Use require with a pre-processor. But given a build-step of this 
complexity, see 3.

3. Use an ES6 -> ES5 compiler. Some very big sites are already doing 
this, I'm not sure whether I can name them all but they open source 
their tools. Google Traceur is just one example.

Coding for ES5 and ES6 by hand is costly, but there will be ES6-only 
environments (a future Node.js release, for one).

On the web browser content side, one could choose any of the above, but 
the only one that both gives early error checking and stands to become 
the next-generation standard is (3).

> Ideally, the interop solution would make upgrading to ES6 module 
> syntax transparent on the import side.  But that's going to require 
> dynamic modules (or perhaps some kind of static/dynamic hybrid).

We've been around this block for over two years. There is no such hybrid 
unless you add a special form such as import, or |require("...")| at top 
level, and that can't be done backward-compatibly using only functions 
(i.e., a library shim, AKA a polyfill). You'd need a preprocessor, in 
which case why not (3)?

> It seems that we're in a situation where either interop or 
> "static-ness" are going to suffer.  Isaac, as a Node developer and 
> architect, what is your take on this situation?

Interop of Node.js modules is good due to synchronous require. Interop 
across Node and browser is not so good, due to among other problems lack 
of sync. require on the browser side.

Therefore in any evolutionary path from here, interop is going to suffer 
on the browser side. (1) and (2) have enough usability problems that 
people still use ad-hoc concatenation and <script>-based techniques.

> Note that the same trade-off exists on the browser-side. 
>  "Forward-compatible" modules on the client are going to necessitate 
> dynamic modules as well.  James, what is your take?

It's no use pretending we have some great module story on the web 
browser side, with which to preserve "interop". We don't have any such 

All credit to James for working with the existing semantic tools in the 
language, but when there is a semantic gap, TC39's job is to consider 
filling it.

"Interop" in general needs some compilation step because of the 
differences among all of ES5, ES6, Node.js's sync. require vs. the 
browser's async.

"Interop" meaning no new semantics signified by new syntax is a false 
economy and something the Harmony agenda explicitly rejected. "No new 
syntax" was ES3.1's mantra and we left that behind in founding Harmony:


More information about the es-discuss mailing list