In general (although there are some exceptions), having one large concatenated JS file, properly GZIPed, pushed to an asset bucket (like Amazon), pulled from a CDN (like Cloundfront), is the best way to go. Yes, you can split your manifests into different sub-sections, and load only “what you need” on any given page, but for most apps – even large apps – you just get batter overall performance with one JS file.
Sometimes as a middle-ground I will create different manifests (and load them separately) for different areas of my website – like one for the user-facing and a different one for the admin-facing sections. That can be a good middle of the road approach. Or, if you have a public facing site that has one set of JS and a dashboard for only a subset of users, you could have different manifests for each.
I think that if every page and every controller loaded a different JS, you’d simply be slowing down the user’s experience by making all those files load as the user moved through the website.
Let me put it this way: You’re going to get so much more of a speed increase from properly gzipping and moving your assets to a CDN, that your strategy of splitting up your website into separate JS is like saying we should upgrade the gears on our bicycle when the right thing to do is replace the bicycle with a car.
For sure, but it would be a relatively small file, wouldn’t it? There’s a lot of (reasonable) concern about making multiple HTTP requests, but that’s usually when you’re evaluating the performance of a single page. As you go between pages you’d be just loading what you need.
Well no, actually, the way it is supposed to work is that only the first page loads the needed JS, and all other subsequent page loads will use the same JS file from cache, so you really are speeding up the user’s load time on all subsequent page visits after the first one.
Outside of Rails, JS developers are working in Node, or PHP(!), or lots of other back-end options. They are writing thick-client Angular apps or Ember apps that talk strictly via JSON APIs to the back-end. A lot of these languages are new, and are having growing pains, but they are evolving our understanding of how to think about a distributed client-server application and address a lot of the headaches with structural advancement.