Because you're making dubious gains saving a couple KB of bandwidth by sacrificing the responsiveness of your app when you introduce an additional round trip for each new piece of code. It may look fine for you, but there are plenty of people that don't have super-low latency, high bandwidth internet connections.
It's important to understand that there are tradeoffs with lazy loading. There's a spectrum, right?
On one end, you could serve all of your js bundled with browserify on the first page load, which, for SPA's will frequently block rendering until the entire bundle is downloaded, parsed, and executed. If your bundle is small, who cares? Once your app grows to a large enough size, that initial delay might no longer be worth it.
On the other end, you could serve almost no assets with the initial page load, and request what you need when you need it. Your initial render will be blazingly fast but any first interaction might be slowed by the latency involved in going to get the relevant assets needed to execute the interaction.
Somewhere in the middle you may find a solution involving sending half of your assets initially and requesting the other half when you need them.
It's not helpful to write off various methods of asset loading because of assumptions about latency, bundle size, or DOMContentLoaded event delay. The important part of this article is that it speaks to the various approaches to this problem. I'm guessing the author took the time to weigh the pros and cons of these approaches, chose this one which particularly works for him, and wrote about it to share his findings.
This isn't a trivial problem with one solution. Dig into the performance of your apps while wearing multiple hats and take what works best for your situation ;)
Well put. My (and, I think others) concern with the article is that it advocates splitting all your code into separate files (great for maintainability and managing your code base), but then loading each of them individually on demand (probably a bad idea for all the reasons everyone's mentioned). I'm a lead dev on a fairly large JavaScript app, and we've taken that middle route - we use build process with Grunt and RequireJS to compile our 300+ individual script files into a handful of concatenated files divvied up by page/component. Our application is large enough that loading everything at once (even concatenated/minified/gzipped) doesn't make sense, but RequireJS/the r.js optimizer made it really easy to both figure out our usage pattern and consolidate our core set of modules. The process we use creates a different version of our app script for each entry page, and then each page has its own separate module that can be loaded on navigation.
Definitely, and I think your concerns are valid, but if you found that loading each file on demand yielded the optimal performance for your app, wouldn't you go with it? Additionally, I think the method the author is presenting can be very well suited to both partial bundles and individual files. For what it's worth, you and I are in similar positions and it sounds like we have very similar approaches with our own apps. As long as readers understand that this is one possible solution to a nontrivial problem, I'm happy with it.
