Static Module Resolution
brendan at mozilla.org
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
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
"Interop" in general needs some compilation step because of the
differences among all of ES5, ES6, Node.js's sync. require vs. the
"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