Echo JS 0.11.0

I'm dodging the problem because that's what you probably should do. Deep recursion brings a lot of problems in JavaScript - first of all, the stack's depth.

But you don't seem to even need that stack, since you're ready to use setTimeout, discarding the closure's scope: that's actually a clear sign that you should use another approach, probably iterative. That would give you a good performance boost too.

That's why using setTimeout is generally frowned upon: it's a hack to get over a language limitation that could be solved with other, more efficient techniques.

So I don't recommend using setTimeout, because I don't recommend using recursion in the first place. Tail call optimization, where available, could solve the depth problem but it won't yield a performance as good as an iterative approach.

The first thing to ask yourself is: why do I need such a deep recursion in the first place? Isn't there a better way?

Not JavaScript.

Nice, didn't know that. Kind of reminds me of Lwip (https://github.com/EyalAr/lwip) but it's entirely in JavaScript. I wonder if it keeps up with the speed.

The one you provided in the post. But now it seems to be fine.
Anyway, that service won't gain any success until served on https.

Welcomed by an Application error: "An error occurred in the application and your page could not be served. If you are the application owner, check your logs for details."

What a great start.

Man, the documentation there is all over the place... I have no clue of what that's about!

It seems to me it's more or less a patchwork of old and future features of JavaScript, including:
- `do` expressions
- pattern matching
- comprehensions
all with some CoffeeScript flavor. Throw in the mix JSX and Flow.

I'm not attracted to that at the moment. Except for JSX, everything else is pretty much in the backlog of EcmaScript.

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.