Tree-Shaking: A Reference Guide | Hacker News Reader

Tree-Shaking: A Reference Guide

smashingmagazine.com

The Web development scene is sometimes just so foreign thing to me. I've many times wondered, what does tree-shaking mean when listed in some features in some framework. I think I've looked up it in several occasions and it hasn't stuck with me. It throws me off as it sounds like some kind of ast fuzzing or whatever (perhaps like heckle in ruby).

There is a perfectly good name for this that is used in many other contexts, called "dead code elimination", which is also fairly self-explanatory if you haven't come across the term before.

afaik tree-shaking is an old old term, it might be less obvious in the web context because it's probably inherited from 70s programming languages (lisp, smalltalk or similar, i can't really say).

Yes, in image based languages DCE is used inside functions to eliminate things like branches that can never be executed, but a function that is never called is not dead code since it might get called later. Tree shaking is used to optimize the final deliverable by saying that there will be no more changes or `eval`s, so anything that isn't reachable from the root(s) can be eliminated.

Whether dead-code elimination would remove whole functions depends on some basic assumption of the tool doing it --- usually a compiler. Some languages are considered closed worlds whereas others are usually considered as open worlds, e.g. Smalltalk, Java and Lisp. Under an open world assumption, everything that could be called by some code added later has to be retained. Some tools nevertheless apply a closed-world assumption to an "open world language" and take additionaly arguments what to consider entry points that should be retained. An example for such a tool is Proguard in the Java world.

Adding to the confusion is this often-cited article: https://medium.com/@Rich_Harris/tree-shaking-versus-dead-cod...

That article claims that "tree shaking" is different because:

> Rather than excluding dead code, we’re including live code.

That's a misunderstanding of the term "dead code elimination". Classic dead code elimination techniques have always worked by first identifying potentially live code and then eliminating the rest.

Yeah this is just Rich Harris trying to sound smart it seems. I always had a problem with that exact quote because it's just another web-delusional attempt at reinventing the wheel with a flashier name.

Tree Shaking is dead code removal. They're one and the same.

FWIW, this Twitter thread addresses this issue: https://twitter.com/Rich_Harris/status/1305925515472261122.

I certainly didn't _invent_ the term 'treeshaking', I merely (unwittingly) helped popularise it in the JS ecosystem. The relevant parts of the Twitter thread:

> the reality is that at the time i wrote that, when Rollup was in its early stages, minifiers empirically didn't eliminate as much code as Rollup did

> i think it's worth looking at this from the perspective of the respective terms' connotations, rather than the strictly technical definition (which i agree has been overstated; mea culpa for my part in that). DCE is something you do to programs; treeshaking is what you do to libraries. It may be the same thing, but the prevalence of the idea of treeshaking has put the onus on library authors to make their libraries DCE-able, in a way that has coincided with the adoption of ESM

The author correctly states that you need imports to be statically analyzable for this to work. However, he then wrongfully states that this is achieved because ES6 imports can only be at the top level instead of conditionally nested. This is wrong.

What makes ES6 imports static analyzable is the fact that you are forced to name exported/imported symbols individually (instead of exporting objects as with commonjs) and the fact that module identifiers have to be string literals. You can keep these 2 properties even when you'd nest imports.

In fact, there's an ES proposal form the author of reify to support this in ES, which explains this further: https://github.com/benjamn/reify/blob/master/PROPOSAL.md

The article doesn't mention ES2020 dynamic imports of ESM modules.

Reply on news.ycombinator.com