Rich Harris

> I also fundamentally disagree that plugin repos are a good idea

Part of the reason I was motivated to do this work is that I love Three's batteries-included approach – I don't need to spend a long time configuring my project or trying to figure out how to glue different libraries together (I've written more about this here https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4#.sckmgwnd6). Nothing has changed vis-a-vis Three being a drop-in file.

But it's a double-edged sword – batteries-included historically means including code that you're not using in your project. ES modules give us the best of both worlds via tree-shaking. And once you've learned them (you're not learning Rollup, you're learning JavaScript – this is a standard we're talking about) you'll find it's much more logical than the alternative. Trust me!

The KeyframeTrack thing is just a special case resulting from the codebase's history. It could easily be fixed more elegantly, it was just outside the scope of this PR.

the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo:

- ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go binary))

- Deno

- Rome

As we consolidate on the jobs to be done we expect out of modern tooling, it makes sense to do all these in a single pass with coherent tooling. It will not make sense for a large swathe of legacy setups, but once these tools are battle tested, they would be my clear choice for greenfield projects.

recommended related reads:

- https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4

- (mine) https://www.swyx.io/writing/js-third-age/

I've been reading about tree shaking. I'm not at my laptop at the moment, so I can't settle this question by testing it. I'll toss it to the community:

https://news.ycombinator.com/item?id=11349606

Basically, how does tree shaking deal with dynamic inclusions? Are dynamic inclusions simply not allowed? But in that case, what about eval? Is eval just not allowed to import anything?

I've been reading posts like these, but they are pretty unsatisfying regarding technical detail: https://medium.com/@Rich_Harris/tree-shaking-versus-dead-code-elimination-d3765df85c80

Maybe someone else was wondering the same thing, so I decided to post it here before wandering off to the ES6 spec to figure it out.

Well it wasn't that you weren't being specific, more that you were casually maligning the JS community unfairly, when the article isn't even about web/JS :)

(I also don't agree with 'don't need to'. The main takeaway from the leftpad debarcle was the fixes to the npm module deletion policy, and hopefully people learning they shouldn't rely on an 'npm install' for production deployments! Whether people should use small modules is still up for debate, there are trade-offs [1] [2]).

[1] https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328
[2] https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4

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

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.