This was really great listen. I don't have an anti-bundling stance fwiw. I just think it's a poor starting point.
https://syntax.fm/show/848/web-components-can-t-save-us-with-scott-jehl
And, not just 'an opinion'. Go use web page test or page speed insights or lighthouse and measure anything on https://enhance.dev/showcase to see what I mean. Bundling isn't required or even desirable for performance. It's an optimization and, frankly, a code smell at this point.
A good CDN should automatically brotli/gzip. A smart dev should be aware of and avoid waterfalls. Voila. One less tool to maintain and now the code you write is the code that runs which, I think, we can all agree is good.
I agree. Using a new function in a library and seeing your bundle becoming unbearably big is not a nice thing to happen.
I'm not really a fan of CDNs, because of privacy, security and reliability issues (I can't guarantee anything about a file that is owned by people I don't know, and can be bought and replaced by someone nasty). If my server can serve a file, why use another people's server? Caching is very unlikely to be a reason, since the probability of my users visiting another site using the same CDN to serve the same library in the same version and the same file variant is really tiny.
The decision to bundle, transpile or use a CDN is akin to caching: don't do unless it is really needed. Most of they time, you will find it is a hassle with no practical benefit.
Years ago, they made sense, but now we have HTTP compression (so file size doesn't always mean slower sites), HTTP 2 (so your server is 'bundling' your files anyway), faster networks (so the effect of using them may be insignificant for your users) and usually no need to cater to old browsers penalizing the browsers 99% of visitors are using.
