I don't understand why TC39 had to define a new syntax, new semantics, and new restrictions for modules in JS land when the JS community had already created solutions for modules in JS. People were using modules in JS before they knew that "loader" or "static import/exports" 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'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.
And all this "tree-shaking" 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/amd/umd way with a slightly more intelligent bundler. And the new "syntax" that they created is just a variant of destructuring. You can achieve nearly the same with ES6 destructuring and `require`.
sigh
CommonJS is anything but - the synchronous loading and node-style resolution doesn't work well over a network, and the scoping doesn't work out-of-the-box in a browser. I wish node had just discovered and used AMD-style modules.
AMD is pretty great for what it is, IMO. It's minimal, it works (without transpilation!), and it's pretty easy to understand how and why given the language and environment it's defined for. I'm kind of sad that it "lost" to CommonJS. Still, the syntax (even though given JS, it really just falls out) isn't preferable, and it's still imperative, which makes tooling more difficult.
Modules give a better syntax than either CommonJS or AMD, with asynchronous loading that works on a networks, and imports and exports are declarative so that tools are easy to write.
Tree-shaking and static analysis are only possible with CommonJS/AMD if you strictly limit them to declarative-style use: imports at the top-level only, exports as a literal, etc. Deviate from that and tools trip up. In that case, it's better to have a new, clear, declarative-only syntax.
answered below in https://news.ycombinator.com/item?id=11491590
> and the scoping doesn't work out-of-the-box in a browser
sorry, didn't get you on this one. Example?
> Tree-shaking and static analysis are only possible with CommonJS/AMD if you strictly limit them to declarative-style use: imports at the top-level only, exports as a literal, etc. Deviate from that and tools trip up. In that case, it's better to have a new, clear, declarative-only syntax.
Agreed with the former part, but I am not sure how the new syntax is better and clear. Infact the new syntax imposes limitations. The old regular would just not optimize in some cases. You won't lose anything or any optimization.
Further, the "top-level" only is a bit of an itch. I want to be able to do this:
if (DEBUG) {
import 'something';
}
You/someone might very well have an answer for that - honest question, not mocking :)
An async implementation of `require` would still be subject to most of the same debate and complications of the "Loader" (how are module names converted to URL paths; how are URL paths deduplicated from being downloaded more than once or ran more than once; ...). You can't assume "Node-like" semantics in the browser (where it's more often more costly to walk the remote file system) and even amongst AMD solutions you'll find variations in how options are configured and how the different loaders work.
TC39 getting the syntax into ES2015 was as much a signal to WHATWG to stop kicking the "Loader" debate can down the road and actually make decisions and get things standardized as anything else. It's easy to believe that without that commitment of dedicated syntax in the language that the browsers would be a lot less incentivized, we'd still be having the Loader debate in 10 years and we'd still have increasingly subtle differences in AMD loaders and CommonJS loaders, and that nice new "async implementation of require" would continue to just be one option among many, with twelve different libraries implementing it in slightly different ways.
Personally, I think the ES2015 import/export syntax is much more aesthetically pleasing than AMD, and nicer to work with than CommonJS, but I can appreciate that there are plenty of aesthetic opinions on the subject.
The same applies to module.exports, the final set of exports from a module can only be determined by executing that module. While you can spot common patterns, ultimately JS is, again, Turing complete, so the code has to be executed. In practice, this is frequently an issue as modules often use sophisticated logic to build up their exports.
So it's impossible to statically analyse all such dynamic modules, which is why the ES6 module system is static. This is a big win as it allows tree-shaking to be done with 100% safety.
Also note that the ES6 import syntax opens up future possibilities which are not possible by destructuring require, for example type annotations look set to come to JS and destructuring can't be used to import a type, because types are not values.
Seriously? Code organisation and globals are massive pain points; pre- CommonJS/AMD/UMD we needed both boilerplate + strict conventions, post- , well, they're all dependencies, they all need toolchains. Why should I not want to remove dependencies with something that is syntactically and practically extremely simple? I guess there may be a few JS programmers rubbing their hands at the thought of another bundler and another dependency to add to the toolchain (but it's better this time! promise! just install another 200 NPM modules and off we tootle into JS bliss!), I dunno?
It really is just that JS land hacked up something together and it worked great. Had the community went to lengths as much as people in the TC, we would have had much better everything, but it is a problem already solved enough that people don't care much.
async and dynamic import can always be added later, if demand is great enough for them. Simpler is better to start off with, and require still works just fine (and extensions to require can easily be built on existing primitives).
> And the new "syntax" that they created is just a variant of destructuring.
Yeah, that was the point.
How can you do it for this?
require(someRuntimeVariable);
If not, then it won't :) But you still would have the same benefits when requiring stuff with plain string literals, and additionally you'd have the freedom to require dynamic stuff on the cost of lesser optimizations. You don't lose anything.
1. import and export syntax, this is defined in ES2015. It's just syntax, it doesn't explain how modules should be loaded.
2. The Loader spec (http://whatwg.github.io/loader/) 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/export syntax doesn't allow). We use this extensively in StealJS (or at least an older version of it) and it's pretty powerful.
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't use a regular script tag, modules are different; they are strict mode by default for example.
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'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.
I don't blame them for doing this, Loader has taken too long and people are clamoring for something. The Loader spec has a weird history; it was close to being done in ES2015 but when it was ejected it sit for a long 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]
At this point I wouldn't be surprised to see Loader go away. It'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's own this. This is going to make writing portable JavaScript as annoying going forward as it's always been.
[2] https://html.spec.whatwg.org/multipage/webappapis.html#modul...
This means that modules will either still have to be compiled with something like browserify that resolves modules names into URLs ahead of time (a solution I don't particularly like), or modules will just have to use URLs to import other modules, leading to a convention of assuming that modules are all siblings so that you import like this:
import * as jquery from '../jquery/jquery.js';
import * as jquery from '/js/jquery/jquery.js';
import * as jquery from '/js/jquery';In python there's a library called "sh" and it has a novelty interface:
from sh import ls, pwd, my_unique_command
print ls('/dir')
...
[1] https://bugs.chromium.org/p/v8/issues/detail?id=1569
Since when does FF not matter anymore?
FF48 and Edge 14 don't do so badly either. If you drill down into their missing test cases, it's largely features that few people care about.
In practice, browsers usually try to not do that sort of thing, of course. But note the double-caveat there. ;)
I wish I could afford to ignore Internet Explorer... if Microsoft leaves Windows 7 to rot with IE 11, corporate users are going to keep holding back the web for a few more years.
Support is going to roll out in 3 steps:
1. A system that converts <script type=module> to HTML imports so that loading and ordering is consistent across JS and HTML imports. The converter will run in `polytool build` (polytool is the Polymer CLI in development) and in `polytool serve` (the dev server).
2a. Chrome's implementation of <script type=module> will work correctly with HTML imports, so that HTML imports wait on any JS modules and their transitive dependencies before signaling ready.
2b. The HTML imports polyfill will wait for JS modules to load (this might require no work).
3. HTML imports itself is being re-imagined as a layer on top of the JS module loader, so that HTML is just a different file type that can be loaded and participate in the dependency graph. This idea of "HTML Modules" has positive feedback from other browser vendors so far.
Do we really want to add more ways ? Complexity is an enemy of security, it will add more confusion. Maybe we should first disable/remove ways to load and execute JavaScript.
We should also think, if what really need is a client solution or a better tool/system to transform scripts, in a script server side.
Why, what should be clearly answered before thinking in terms of how.
Sometimes having the bigger picture in your head helps.
Like JSLint or "use strict"; didn't remove JavaScript possibilities, it encouraged us to not write insane JavaScript.
They should consider making a document that lists all possibilities to organize code in modules and explain why some are betters than others, then in the same document explain the benefit for new syntax.