Echo JS 0.11.0

bind gives us the basics of function currying, and while the same can be achieved with a higher order function, it's indeed nice to have it natively.

In JavaScript you should generally avoid the keyword this, but in some cases it makes sense. It's usually when we're dealing with component objects (ugh, so often in JSX).

Then the module should rightfully stay out of the bundle.

If you load a module based on a condition, you're doing one of these things:

1. checking something on the client (e.g. if it supports a certain feature) and lazy-load a module (e.g. the polyfill of said feature);
2. checking on the server (e.g. the Accept-Language request header) and the load the module.

In the first case, it's pretty clear you can't (or better, shouldn't) put the module in the bundle, because it would be loaded by everyone regardless if they actually need it.
In the latter, you can't do that either, because it's a condition evaluated at runtime. Unless we're talking about generating bundle files on the fly?

What I mean is that the concept of tree-shaking entirely relies on static imports, and it's perfectly fine to keep dynamic imports out of the bundle.
Every module that could be loaded with import() must be served in separate files.

Your problems will eventually begin when those modules import things that have already been included in the bundle. That's the real catch.

If you really want to bundle everything up anyway, all you have to do is to statically import all those files, and then doing nothing with them. But then you won't even *need* to use import() anyway, because you'll already have everything you need defined in the scope. Much more, probably.
But all this has nothing to do with tree-shaking anyway.

I wouldn't mind a gentle reminder, but not as obtrusive and *definitely* not when I'm in the middle of reading. That seriously bugs the readers.

Man, if there's something I loathe about RisingStack's (usually excellent) articles is that damn popup that bugs me to subscribe to their newsletter...

Ah, yes, I knew I saw something similar somewhere else:
http://codepen.io/hexagoncircle/pen/akWOdE
And it's just a pen.

Bundling them would break the asynchronicity behind import(), i.e. you're not lazy loading anything.

The purpose of lazy loading is to serve just the resources to make the page work and load everything else when needed in order to optimize the data that's being sent. If you bundle everything up, what are you even optimizing?

Only if you want a bundle that comprises every module you need.
But then again, import() will be used to load modules dynamically and *asynchronously*, so their place is actually *not* in such bundles, but in separate files that are lazy-loaded as needed.

Looks like Moment is incompatible with the mere existence of an object named `global`.

I'm so, so very disappointed in this.

Yeah that was my basic idea too. Thanks!

Are you of that party that thinks that every component could (and should) be defined like that?
I'm not React expert but I find it quite a stretch, because there are components that just need internal state, but it's too verbose/cumbersome/overkill to rely on Redux (or anything like that) for the case. Is there a best practice guide for that?