Not enough discussion here of the parts under "Our Optimization Strategies", which was the most …

> tree-shaking their dependencies What tool did they use: Browserify, Webpack, Gulp, Rollup, Babel, Parcel, ESBuild, etc.

> Love seeing websites make smart choices about which work to handle in the server versus the client. The intro community discussion page at https://www.linen.dev/s/linen does need to load 20+ javascript files for some reason to show the latest messages. Whereas messages still show up even if javascript is entirely blocked, just starting from the beginning in 10/2022 (?). So I'm not quite sure if it's as optimized as it can be.

With icons, I've stopped using icon libraries a while back and now import just the SVG code that I need. I'm a big fan of Hero Icons[1] and they offer a way to quickly copy JSX or SVG code to the clipboard to faciliate this workflow. [1]: https://heroicons.com/

FYI there is a middle ground with the AWS SDK. If you don’t need the entire thing (you certainly do not), you can import product specific SDKs as standalone. Still quite a bit fatter than building your own HTTP client, but it’s an easy win if you already use the SDK. ex, an s3 only Java sdk: https://stackoverflow.com/questions/35591248/aws-sdk-for-s3-...

> I have a feeling tons of projects blindly trust that tree-shaking their dependencies will "just work" even though for many libraries it won't! Is there an easier way to verify this than, say, observing the final bundle size and looking inside the JS bundle? I'm not a frontend developer so this is outside my usual area of knowledge.

The same thing happened in a past job for me — we discovered we were included every single icon in FontAwesome. I wrote a codemod script to refactor how we were importing icons so it was treeshakeable. Cut load times from 10s to 2s — was glorious.

> tree-shaking Always fascinated when I hear that JS term for what's essentially dead code elimination.

> Kudos to the Linen team for proactively finding this - I have a feeling tons of projects blindly trust that tree-shaking their dependencies will "just work" even though for many libraries it won't! For one particular microsoft product, this is brought to attention by documentation: https://learn.microsoft.com/en-us/power-apps/developer/compo...