Since you are lazy loading only code that isn’t used up front, in fact, there is _never_ too much code splitting. The only time you would see a “too many bundle problem” is if you were doing it inappropriately (lazy loading code that was needed at that time causing a waterfall effect).
Sorry i just saw this.
If you have a public app that deploys this way, I would be utterly pleased to break it down.
In-fact, I did so last night for a group of individuals in a tweet storm!! Read the whole thread as it’s super insightful.
Your statement about dealing with a change of Sync vs Async is fair but you already are in Async events like navigation occurring events, etc. When a route changes this is after the initial page load and either a framework or your own code is managing the async abstraction so you can definitely things declaratively.
Technically this is inaccurate. The benefits of code splitting is that you are waiting until some async operation/event to trigger to then use `import()` to lazy load the module you need.
It may change a static import to a call expression that returns a promise, however, you will only be code splitting (if done correctly) during an async event/callback/situation.
This is a nice article but as one of the maintainers of webpack I’d like to be authoritative with this criticism. Mainly because it’s being marketed as “correct” but instead, a majority of the reasoning and advice is incorrect.
Just remember, when you use eager, it’s not code splitting anymore and therefore you just incurred all those.lazy chunks JS cost upfront. So you shouldnt ever use eager in production.