3 ms·
Yep, I agree. Optimization is about tradeoffs :) At my day job we use app splitting rather than page splitting. Instead of breaking our codebase into individua
by Swizec 9y ago
Yep, I agree. Optimization is about tradeoffs :)
At my day job we use app splitting rather than page splitting. Instead of breaking our codebase into individual pages and loading only those files, it's broken into apps. So you might load too much stuff for what you're currently doing, but you're never loading code that's completely unrelated.
A downside to that is that if you hit all our apps in one browsing session, you might download some vendor libraries like 10 times. But it's unlikely that a real user would ever do that.
- eterm 9y ago> you might download some vendor libraries like 10 times That reminds me that I once found 3 versions of jquery (or perhaps jquery-ui, my memory fades) linked from the same page. One was linked in the master (yes, this was webforms), one was being injected through a user control and the last was written into the page. All three were all different versions so were all being downloaded. This came to light when a controls stopped working when one version was 'updated'.
- lucaspiller 9y agoWe do something similar, but common code is shared. Webpack has a feature called chunking which we use to put everything from node_modules into it's own bundle which is loaded across multiple apps. Then the app specific code is loaded on each page. https://webpack.js.org/plugins/commons-chunk-plugin https://webpack.js.org/plugins/commons-chunk-plugin It does result in code being loaded when it isn't always needed, but in our case most libraries are used in every app.