Search code examples
javascriptecmascript-6ecmascript-harmony

How will ECMAScript 6 Harmony modules be managed in HTML script tags?

I realize this is not yet implemented and so hypothetical.

When ES6 Harmony modules are eventually implemented in modern browsers how will the syntax and implementation handle inline JavaScript? By comparison I can imagine the conceptual distinction that each file is considered a module lending to the idea that an HTML document will have a <script src="..."> tag for each individual module.

However, this seems odd in the browser as it means if you have 50 modules you now have 50 client/server connections. Another problem would be introduced if you concatenated the files or possibly inline several modules in a <script>...</script> tag.

Ultimately this would conflate the global / name spacing problem:

<script>
  var Foo = {};
  var Baz = 1; // Local or Global?
  export default Foo;

  import Foo in 'foo';
  var Bar = {};
  var Baz = 2; // Local or Global?
  export default Bar;
</script>

In CommonJS -> trans-piled or AMD everything is wrapped in a closure. Leading me to believe that when ES6 comes out we will still have to wrap our code:

<script>
  (function() {
    var Foo = {};
    var Baz = 1; // Definitely Local now!
    export default Foo;
  })();

  (function() {
    import Foo in 'foo';
    var Bar = {};
    var Baz = 2; // Definitely Local now!
    export default Bar;
  })();
</script>

How will future implementations of ES6 Harmony modules handle the browser's flat dependency model of concatenated sources?

Solution

  • Modules can be concatenated together without issue with the module SomeName { /* module contents here */ } syntax.

    EDIT: The module block syntax has been dropped from the spec. The conclusions of the committee seems to be that concatenation is a hack to work around a limitation of HTTP 1. The ultimate solution is to have an HTTP 2 aware server and client so that the client can multiplex its requests and the server can push additional resources to the client (Thanks Andreas!)

    As for dealing with module semantics in the browser, a separate <module> tag was introduced for creating individual modules on the page. (Since modules can be resolved asynchronously, they don't match the semantics of inline script elements, hence the need for a new tag).

    See also: