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 story.
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:
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
