Adding JavaScript modules to the web platform

This comment is gonna be bikeshedding, and definitely not a popular opinion in today&#x27;s &quot;modern&quot; JS community, but here it goes anyways...<p>I don&#x27;t understand why TC39 had to define a new syntax, new semantics, and new <i>restrictions</i> for modules in JS land when the JS community had <i>already</i> created solutions for modules in JS. People were using modules in JS before they knew that &quot;loader&quot; or &quot;static import&#x2F;exports&quot; were a thing to be landed in ES6 in future. And frankly, what the JS community made for themselves was a lot more saner than what is coming natively to JS, and even more so compared to the native solutions for module loading in some other languages (compare to Python for example). I don&#x27;t think any JS programmer wanted modules natively in JS. And with HTTP2, they would have just stopped bundling and a newer async implementation of `require` would have been conjured.<p>And all this &quot;tree-shaking&quot; etc. that is claimed to be possible only with the static syntax is blatantly incorrect. It is entirely possible to eliminate unused code with the commonjs&#x2F;amd&#x2F;umd way with a slightly more intelligent bundler. And the new &quot;syntax&quot; that they created is just a variant of destructuring. You can achieve nearly the same with ES6 destructuring and `require`.<p><i>sigh</i>

If you don&#x27;t find JavaScript modules confusing, you should. I work on a module loader [1] and I find it quite confusing. To clarify we have 3 things:<p>1. import and export syntax, this is defined in ES2015. It&#x27;s just syntax, it doesn&#x27;t explain how modules should be loaded.<p>2. The Loader spec (<a href="http:&#x2F;&#x2F;whatwg.github.io&#x2F;loader&#x2F;" rel="nofollow">http:&#x2F;&#x2F;whatwg.github.io&#x2F;loader&#x2F;</a>) which defines a full loader including hooks to do just about anything you can possibly need. This allows you to do really crazy things like define modules dynamically and import then dynamically (which the static import&#x2F;export syntax doesn&#x27;t allow). We use this extensively in StealJS (or at least an older version of it) and it&#x27;s pretty powerful.<p>3. import type=module is what this article is referring to. It defines a tag that allows you to import modules in the browser. You can&#x27;t use a regular script tag, modules are different; they are strict mode by default for example.<p>If you read the GitHub issue there was some discussion of whether import type=module should use the Loader spec. It probably should. But the Loader spec isn&#x27;t done so... reading the spec and seeing things like the module map [2] it sounds like import type=script defines a miniature sized loader.<p>I don&#x27;t blame them for doing this, Loader has taken too long and people are clamoring for <i>something</i>. The Loader spec has a weird history; it was close to being done in ES2015 but when it was ejected it sit for a <i>long</i> time without much work. Then around last summer it was heavily worked on and got pretty far. But now as it sits, no commits like the last 2 and a half months [3]<p>At this point I wouldn&#x27;t be surprised to see Loader go away. It&#x27;s probably too controversially and too big to ever get done. I imagine the web will just have the import type=module loader and Node will do it&#x27;s own this. This is going to make writing portable JavaScript as annoying going forward as it&#x27;s always been.<p>[1] <a href="http:&#x2F;&#x2F;stealjs.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;stealjs.com&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;webappapis.html#module-map" rel="nofollow">https:&#x2F;&#x2F;html.spec.whatwg.org&#x2F;multipage&#x2F;webappapis.html#modul...</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;whatwg&#x2F;loader&#x2F;commits" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;whatwg&#x2F;loader&#x2F;commits</a>

This is huge. Finalization of the module loader spec is usually what&#x27;s cited as the last remaining blocker for full implementation of modules in V8 [1]. Combined with HTTP2 being available nearly everywhere [2] and native ES6 support soon reaching most mainstream browsers [3], it means that web developers will soon be able to drop a large portion of the current JS stack, including spriting, Webpack, and Babel.<p>[1] <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;v8&#x2F;issues&#x2F;detail?id=1569" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;v8&#x2F;issues&#x2F;detail?id=1569</a><p>[2] <a href="http:&#x2F;&#x2F;caniuse.com&#x2F;#search=http2" rel="nofollow">http:&#x2F;&#x2F;caniuse.com&#x2F;#search=http2</a><p>[3] <a href="https:&#x2F;&#x2F;kangax.github.io&#x2F;compat-table&#x2F;es6&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kangax.github.io&#x2F;compat-table&#x2F;es6&#x2F;</a>

Can you use &lt;script type=&quot;module&quot;&gt; with web components&#x2F;Polymer (in a sane way, e.g. without duplicates being loaded like with the old &lt;script&gt; tag)?

There are many ways to load and execute JavaScript, static&#x2F;dynamic adding a script tag to the html, html imports, manual fetch + eval , concatenation of javascript files in 1 file, in the future maybe the import syntax ? and now &lt;script module&gt; ?<p>Do we really want to add more ways ? Complexity is an enemy of security, it will add more confusion. Maybe we should first disable&#x2F;remove ways to load and execute JavaScript.<p>We should also think, if what really need is a client solution or a better tool&#x2F;system to transform scripts, in a script server side.<p>Why, what should be clearly answered before thinking in terms of how.<p>Sometimes having the bigger picture in your head helps.