Hacker News Reader

The existing solutions that the JS community had created were insufficient.

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.

> the synchronous loading and node-style resolution doesn't work well over a network

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';
    }

which is a common usecase and something the builder can easily remove at build time. But ES treats that as a syntax error. The "old" way doesn't have this limitation. Surely the builder's grammar can be extended to support this with the new syntax, but it just feels more magical and weird.

You/someone might very well have an answer for that - honest question, not mocking :)

Replace your debug versions of libraries with stubs that contain no-ops. So in your code, just do:

  import 'something';

And then create separate versions of 'something.js' for debug and release, where your release version just has stubs:

  export function debugPrint(msg) {}

While the debug version might use console.log or winston or whatever.

If you compile your JS and the compiler provides tree-shaking, the calls will get optimized out entirely. Even if you don't, you can deploy the no-ops to prod and it'll use minimal bandwidth and no CPU time. And the best part is that it keeps the syntax of your code very clean; you don't have to litter your code with "if (DEBUG)", you just have it do what it needs to and those calls will equal doing nothing in prod.

(Not OP) Usually when I am using this technique it's for some 3rd party library that provides a useful debugging tool. To use your suggestions I'd need to create a wrapper that calls through to the 3rd party library in dev. Sounds like a huge pain.

You should be able to use Loader config for some of this: With the right plugin to your Loader you could do things similar to AOP/injection in debug/dev with a suitably complex Loader or set of Loader plugins.

Arguably things like this are part of why standardizing the Loader APIs has been so complex. But eventually it may pay out by letting you do some nice things very simply and in a way that is configurable for different environments and also transparent from your configuration how complicated or not your libraries and plugins may be set up. (Whereas dynamic rewriting in memory and dynamic loading and lots of scattered if() blocks can feel much more opaque.)

You'll be able to do that with System.import, kind of. It's async, and it returns a promise, which is sensible but it makes code a bit more complicated.

The ECMAScript wiki appears to be down but this polyfill has a good overview:

https://github.com/ModuleLoader/es6-module-loader

If you look at how browserify/webpack works, you'll see that AMD is the same thing except that you're coding the module wrappers by yourself manually, when browserify & webpack does it for you.

Right, so AMD works in the browser, and CommonJS doesn't. Tools can transform CommonJS to behave like AMD.

oh man, you're confused. AMD was originally a CommonJS compiler in its very early days. The guy who wrote it invented its own standard (AMD) way later than CommonJS.

How am I confused? AMD works in the browser, CommonJS doesn't. It's very simple, and tools that convert CommonJS to a format that works in the browser only prove that it doesn't.

The history of the formats does not change the facts of how they operate today.

At the very least, a first class syntax shows a different commitment level. Building a syntax into ES2015 states a definite, intended, and considered effort to deal with modules as a key part of the language moving forward.

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.

It's not possible to eliminate unused code safely with CommonJS. require is entirely dynamic and can be used in arbitrary ways. It's impossible to analyse all such uses correctly, after all JS is Turing complete, so you're going to have to solve the halting problem first! In practice, this issue doesn't come up much, but some modules do use dynamic loading.

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.

Considering that anything more complex than a primitive in JS is implemented as a prototype chain attached to a first-class-function constructor, I'd say that, in JS, types are absolutely values.

> I don't think any JS programmer wanted modules natively in JS

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?

Well, the biggest issue with using "require" (commonjs) is it is by definition synchronous. That works okay for server side when files are accessible (not best practice though) but it gets really difficult with network resources. JS modules are supposed to be a way to get the advantages with aynchronous module loading (as in require.js) without all of the callback hell.

Again, that is just an issue with the current implementation of the commonjs require. You can, for example, have a require implementation which runs your code inside a `GeneratorFunction` instead of a regular `Function` and use `yield require(...)` instead of just `require`, where `require` returns a promise and is async, and use something like `co` or bluebird's `coroutine` etc.. There is also AMD which is by definition async and gives you the same static export/import as ES6, leave for the new syntax.

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.

but you would still have to be executing the file as code before knowing what it will require

> And with HTTP2, they would have just stopped bundling and a newer async implementation of `require` would have been conjured.

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.

> It is entirely possible to eliminate unused code with the commonjs/amd/umd way with a slightly more intelligent bundler.

How can you do it for this?

require(someRuntimeVariable);

If the `someRuntimeVariable` is statically evaluate-able, then some compilers (uglifyjs, for instance) support limited inline evaluation at compile time, which could be enhanced by community effort.

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.

Nope. If we're talking about tree-shaking (which we should be as it's the entire point in having static modules), you loose everything. That's because require(someRuntimeVariable) can refer to any module. So there's no way to exclude any of the node_modules, or any portions of any of them.

So all code in all modules must be kept. No tree-shaking for you.