danielschaffer

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.

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.

I'm not sure what happened to my comment, so here's the back story:

This is my first "real" app I've written in node.js.

This app came to be because the last time I changed jobs, I went from getting paid once a month to once every two weeks. Since two weeks doesn't quite line up the way once a month does, I had a hard time figuring out how much money I needed to set aside to get into the new rhythm. So, I wrote a little script that figured it out for me.

I wanted to play around with node.js, so it was a great excuse to create full app. Let me know what you think!