That's exactly what my team told me when we transitionned to an SPA. Turns out, splitting properly an SPA is complex and bundling is pretty annoying at the moment.
Why? I think most modern bundlers and spa routers supports code splitting out of the box by just using dynamic imports, aka:
`const myComponent = await import("/path/to/component")`
I don't understand your concern with it and why this is a problem.
I haven't personally noticed the vite/esbuild memory consumption, but I also run build only once at the end before deployment or generating the prod artifacts.
It wouldn't be an issue if other work tools were taking absolutely nothing yes but as it is now, 16GB of RAM with a JS oriented stack isn't enough anymore.
And getting more RAM is just delaying the problem anyways since it takes more RAM every week as the product evolves.
Yeah we all collectively had a look at it and there's not a lot of solutions available. The bundler needs to bundle everything at some point and you are going to pay the SPA tax.
That's why I personally don't recommend SPAs, it introduce a whole other class of issues on top of what you usually deal with. Google makes it work with Gmail and Youtube but it's Google, they can throw infinite engineers at any problem and could make those in pretty much anything.
I agree there is a complexity cost for bundlers. Whether to pay it is an equation that roughly aligns with how robust and interactive your client offering needs to be. Applications probably, websites probably not.
We're a web application and even with those, I'm not sure the bundling is worth it. Customers in some regions complain about the high payload, we made sure the chunks are split properly but with continuous deployment, there's a lot of cache invalidation anyways.
