Continuous Deployment implies at least a few releases per day. Especially for bundled JavaScript (which is most setups) this means you’re invalidating the cache of the entire app at every payload.

Imagine having to download an app update every time someone merged to master. That’s most SPAs.

This can be the case, but if any of the engineers on staff spend a day reading docs it should generally be fixable. A 30mb it should be chunked by the build process in such a way that small updates usually cause cache invalidation for only a few kb worth of files.

If the library you use to build your SPA (React, Vue, etc.) is relatively up to date you should also probably not be sending the whole app over the wire at once to anyone. Routes and components can be set to only load when the user actually attempts to access them inside the SPA, reducing egress significantly.

In Webpack the chunks whose content don't change don't get new file names and so the cache needn't be invalidated for them. Vendor code which is often the largest part, can stay cached over many deployments so long as the versions are locked. Of course, your host could still send no-cache headers and invalidate everything, but that's a problem with the host/cdn.

Sure, I really do hope that engineers do their best to fix things, but in the sad world of contemporary web frontends, I'm a bit pessimistic (then again, if one has to err on the side of build system over-engineering, you're rarey disappointed).

Still, if the deployment system involves frequent node module updates, the vendor files get "dirty" quickly, too.

Sad!? You must not be old enough to remember when we used the global namespace for modules, and there was no console.log(). You wanna talk about sad, try debugging with alert().

I think they are talking about bundling before code-splitting (like we did back in the Browserify days) and that's true, but we have Webpack, or ESModules now.