Take any dicussion to the ES-discuss mailing list!
Edit: This is a draft! If anybody's interested I'll continue working on this (Leave a +1 in the comments). Please use the comments ONLY for spelling/grammar/factual wrongness. Any discussion should go to ES-discuss.
ES Discuss Archives | Download July 2012 Archives
- Modules
- Modules Depending on Old Code
- Static Module Resolution
- Old Module Interoperability
ECMAScript Wiki: Modules Proposal
At the end of June, James Burke raised a question: What happens when a module depends on non-module code?
Burke made the point that introducing new keyword to ECMAScript may make it difficult for module code to use code from non-modules. Burke explained that should a module depend on an old-style script ( say, a script that exports a global variable (attach to window or global if in Node ), it could have different behaviors and end results:
- Unsupported. Error occurs.
- jQuery is suggested to provide a jquery.es.js file that uses the new keywords
- Proposed: When jquery.js is compiled, and no import/module/export modules are found, then the Loader will execute jquery.js to see if it exports a value via a runtime API. It uses that value to then finish wiring up the local jQuery reference for module foo.
-- James Burke
David Herman suggested that old-style scripts could be loaded using a <script> tag. Aymeric Vitte rebuttled and pointed out that server-side environments can't load <script> tags. Vitte also argued that #3 was overly complicated.
Burke responded to Herman raising another point that user's shouldn't have to manage their own dependency trees. Burke argued that writing <script> tags manually into the page made the Harmony module proposal look primitive compared to existing module systems.
In the thread Static Module Resolution, Kevin Smith again raised the issue of modules that were not ES6 modules. Smith questioned whether or not "pure static module resolution" was practical or not, considering old modules exported their values at runtime. Smith though this would create problems for pure static systems, as a pure static system would need to execute dynamic code before the static code was initialized, which would violate the Module proposal's notion of resolving dependencies before executing any code.
John J Barton suggested that the execution context could be modified: that is, non-es6 modules could be executed before ES6 modules ran. Herman liked this approach and also admitted that the strategy for loading non-es6 modules needed more work. Barton suggested trying to force the module to load as an ES6 module. Should that fail, heuristics could be used to load it as an AMD module or a CommonJS module. Barton admitted this approach to be "a hack", but it "only needs to be good enough to get us over the hump."
Smith asked about using require('module/path') syntax instead of import. Brendan Eich said this would not work without a pre-processor (e.g. Browserify, RequireJS optimizer). import, Eich argued, should not work synchronously like Node's require does because browsers shouldn't block for script loading. Eich's feedback against continuing to use require-based modules in ES6, summarized, was:
-
Asynchronous
require(callback after load) was so unpopular with developers that Node implemented a synchronousrequireat the cost of violating its principle of not blocking on I/O. -
Use a pre-processor
-
Use a ES6->ES5 compiler ( e.g. Traceur )
Eich argued that if developers were to use a pre-processor, they should use an ES6->ES5 compiler because it converted modules could both elicit the use of early checking and be guaranteed to be compatible in future versions of ECMAScript.
Eich pointed out that despite the strategy moving forward, commonJS and Node modules, interoperability between these modules and ES6 was going to suffer. While Eich recognized Burke's efforts with AMD and RequireJS in the constraints of ECMAScript 3, he dismissed the idea that there were a great number of browser modules that would need to be preserved for interoperability.
Eich reaffirmed the comittee's decision to create new syntax, stating that interoperability between the synchronous nature of Node modules and the asynchronous nature of the browser would need a build/conversion step anyway, regardless of whether new syntax was introduced or not.
Brandon Bevie recommended allowing for an adapter based approach:
// legacyModule.js
// example by Barton
// exports commonJS/Node modules to ES6
// exports 3 values: legacy1, legacy2, legacy3
export var legacy1 = require( './dep1' ),
legacy2 = require( './dep2' ),
legacy3 = require( './dep3' );
Smith asked Herman about the possibility of a synchronous loader for legacy scripts that require an ES6 module. Eich again stressed the importance of not blocking web page rendering while loading scripts. In a reference to March 2012's TC39 meeting, Eich cited Oliver Hunt's point that nobody wanted a "footgun" like a synchronous loader. Eich referred to Herman's proposal that scripts ( code within <script> tags, specifically not modules ) can't contain static module load statements (such as import or module foo = "path/to/foo" ), and could only use an asynchronous Loader. Modules could use these statements, but could only parse them when loaded dynamically.
Herman stated that a host environment ( such as Node ) implementing a synchronous loader would be allowed, but that the standardized API should be asynchronous but allow for synchronous extensions.
Smith rectified his question on synchronous loaders, emphasising that he meant the use of require for the Node.js environment only ( for module adapters ). Eich stressed that what works for Node as far as synchronous require was a tradeoff and would not translate well to the browser, but both environments should be considered by the Harmony team ( link ):
It would be an unhappy thing to hear Nodesters say "I'm all right, Jack" meaning: synchronous require for us, and the devil take the browser. It was good to hear Isaac affirm that synchronous require was a compromise with Node's "never block" principle motivated by require() usability and the startup vs. non-startup runtime tradeoff.
For my part, I would never say that Node should move to ES6 modules on any definite schedule. Rather, my point is that whatever works for Node because of synchronous require does not carry over to the browser, and therefore Harmony designers have to look at both embeddings.
-- Brendan Eich
No non-email information available. (The filmmaker is the only thing I can get Google to come up with).