,
7 tweets,
2 min read
Read on Twitter
Tree-shaking could be an anti-optimization. The ideal is for your libraries, which change less often than your app code, to be codesplit separately & be barely tree-shaken if at all, so that updates to your app result in unchanged library “chunks” and minimal cache busting (1/x)
What you’d really want is key libraries cached *across* different sites. React, Vue, Lodash, should exist *once* on the user’s computer (*/- versioning). Instead, we micro-optimize locally for our sites, each shipping different subsets as part of larger globs. (2/x)
Ultimately resulting in a much larger sum. 100 different sites each with a different subset of lodash instead of lodash stored once and usable by everyone. This is just the shared library argument of course. (3/x)
It would maybe be interesting if the browser could download only ranges of your compiled JS file (just like it can do with movie files when skipping around). That way you could include lodash in your total glob with integrity hash but is skippable if browser already has it. (4/x)
Anyways, the moral of the story is that it feels that we are doing WAY TOO MUCH work in a local optima of JS compilation that is actually potentially subtly making larger *global* optimizations harder to implement later. It’s a vicious cycle... (5/x)
Tree-shaking leads to less overlap in perceived resources on sites -> this makes the case for great shared resource support in the browser harder to justify -> this pushes for even more ad how local solutions. (6/x)
Something that doesn’t seem to be clear from earlier tweets: this shared caching would be checksum based. This avoids the issue of different CDNs and individual hosting. It’s not a “formal” installation of packages, it’s a much better form of caching.
