Modules: suggestions from the field

James Burke jrburke at
Mon Jun 23 11:45:33 PDT 2014

I added a doc about module inlining/nesting, and why it should be
supported in a module system. Mentions SPDY/HTTP2, packaged formats,
Node’s Browserify, and transpiling:


On Mon, Jun 16, 2014 at 1:21 PM, James Burke <jrburke at> wrote:
> I have suggested alterations to the modules effort, and an in-progress
> prototype[1].
> It is based on field usage of existing JS module systems, and my work
> supporting AMD module solutions for the past few years.
> There is a document describing what it attempts to fix[2]. The table
> of contents from that document:
> This project reuses a lot of thinking that has gone into the
> ECMAScript 6 modules effort so far, but suggests these changes:
> * Parse for module instead of import/export
> * Each module body gets its own unique module object
> * Use function wrapping for module scope
> They are motivated by the following reasons:
> * import syntax disparity with System.import
> * Solves the moduleMeta problem
> * Solves nested modules and allows inlining
> * Easy for base libraries to opt in to ES modules
> It has these tradeoffs:
> * Cycle support
> * Export name checking
> I am willing to talk to TC-39 members in realtime channels (video/in
> person) that may need more background or might want to discuss
> further, but I am less likely to discuss it in email threads.
> I will likely continue that prototype effort even if the more recently
> visible issues for modules are solved differently, as the current
> state of the baseline ES system will still require bootstrap loader
> scripts. For the bootstrap scripts, I will need some of the concepts
> in the prototype for the AMD consumers I have traditionally supported.
> There is a “story time” document[3] for a narrative around how the
> prototype relates to smaller ideas around code referencing and reuse.
> [1]
> [2]
> [3]
> James

More information about the es-discuss mailing list