63

Ok, so I have a reasonable size project, where I'm using jquery backbone and a couple of other javascript libraries. I was wondering if I should have one file for my javascript libraries and another for my custom code. Or a bunch of separate javascript files.

net.uk.sweet
  • 12,444
  • 2
  • 24
  • 42
Jason Silberman
  • 2,471
  • 6
  • 29
  • 47

7 Answers7

98

It is generally a good idea to have fewer HTTP requests. So you should reduce the number of files as much as is reasonable.

My personal preference is to have three "groups" of JavaScript files:

  1. Core file. Contains functions that are used almost everywhere and other useful page initialisation things.
  2. Module files. Contains code that is used in several places, but not everywhere. Can be dropped in to provide additional functionality. For instance, if you have a script to handle date inputs, you could include it as a module file and add it to pages that have date inputs.
  3. Page-specific files. These files contain code that is only used in one place. The only reason they're added as separate files than as part of the page itself is for cache reasons.
Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • 2
    Why not use something like Browserify to bundle all together and serve a single JS file for each page/page template. In this way, you can pick the modules needed for each template in development and bundle together into one minified file. – Nick Jan 22 '20 at 15:36
  • @Nick Because then you're sending the "core" modules repeatedly for every single page, rather than sending one "core" JS file. – Niet the Dark Absol Jan 22 '20 at 19:53
  • 2
    There's no duplication of code and each file can be individually cached in the ServiceWorker. Is this bad practice? – Nick Jan 23 '20 at 14:07
  • are all these answers outdated with http3 and http2 protocols ? – strix25 Jun 20 '23 at 07:19
20

One big file. You should minify the code when it goes to production and compress it if its large. You want to make as few requests to the server as possible to improve page performance

Glenn Ferrie
  • 10,290
  • 3
  • 42
  • 73
  • 3
    I disagree. You should separate your files in the development so you can *read* them, and then have a deployment script which packages it up and compresses it. Nobody likes to read minified code, but that's what you need to provide to the user. – bchurchill Mar 06 '13 at 00:31
  • 29
    @bchurchill - i said in my answer "when it goes to production" - How you maintain your code from project start until you deploy is very transient and irrelevant to app performance. readability at runtime might be nice for teaching but work against performance. – Glenn Ferrie Mar 06 '13 at 00:34
  • 4
    Why would you need all your JS files embedded into one big file ready upon the initial page loading? Google ranks negatively slow initial page loading and you should defer JS files and functions that you don't need upon initial page loading (entry page). – João Pimentel Ferreira Dec 02 '17 at 15:42
  • Moreover i m wondering if this has an impact on performance regarding the browser cache. I mean if i have ony big bundle, if i make a change to one of the files of the bundle, i will have to re cache the whole thing. – Sotiris Zegiannis Apr 16 '22 at 08:03
  • 1
    @SotirisZegiannis - I think you can segment you code. I support that, but I tend towards less files in JavaScript. That said, modern front-end tools do a good job of minifying, bundling and making things as streamlined as possible. so this is less relevant than it was 9(ish) years ago. – Glenn Ferrie Apr 18 '22 at 03:34
11

It's best to separate it out, but not get overzealous. That way you can reuse your library code later. Also, everyone likes working with separate files more because it keeps things more organized.

That said, it's also best to give the user one compressed file so that everything can be cached easily, and this also reduces the number of page requests. Rails 3 does this automatically in the asset pipeline, for example. You can write a script to run your favorite compressor. But you shouldn't sacrifice code readability for this -- you can have your cake and eat it too!

bchurchill
  • 1,410
  • 8
  • 23
  • 1
    People are downvoting because this answer isn't correct. Of course you should split your js into logical components to keep things organized. But you should combine them before sending them off to the user, to keep http requests down. Only split them up into logical caching components with "never likely to change", "somewhat likely to change", and "changes frequently". – Ben Lee Mar 06 '13 at 00:30
  • 3
    ...that's what my answer says to do. You only want the user to cache one big file. – bchurchill Mar 06 '13 at 00:32
  • Ah, you edited your answer since I saw it. (And for the record, I didn't downvote, just trying to explain why the downvotes came in). – Ben Lee Mar 06 '13 at 00:32
  • Yeah, my first answer only had the first portion. I guess I kind of deserved it for not explaining the difference between dev and production clearly the first time. – bchurchill Mar 06 '13 at 00:35
  • @bchurchill i don't think you need readability on production, so its better to minimize http request and network latency to a reasonable amount. readability is only needed at the time of development – Sheelpriy May 19 '16 at 05:30
11

One big file or two files: one small and one big. To be clear, during the development it's good have separate files – maybe using something like requireJS. But when you deploy it, it's good compress everything in one file, in order to reduce the HTTP latency and requests.

I mentioned two files. In some cases, it could be good having one small file, that takes care of the "bootstrap" operations, meanwhile the "big file" – especially if it's really big – is downloaded. This is useful especially for the first access, because users doesn't have your files cached yet.

ZER0
  • 24,846
  • 5
  • 51
  • 54
  • +1, good answer, but I'd also add that you can sometimes squeeze out a bit more performance too by creating two or three "big files" to separate out components that will change very infrequently (e.g. libraries like jquery) and components that will change more frequently (app js). So if you make an app change, the first part will still be cached. Of course, the cost is one more http request, so YMMV and that point. In my apps I typically do that: one file to bootstrap the app and require the others, one for framework js, and one for app js. – Ben Lee Mar 06 '13 at 00:43
  • Sure, it's really depends case by case. I just give a general overview. The idea is that you don't have just two options – one big file or keep all the file separate – but a third one too – a "bootstrap" file, and then the rest. You can adapt it base on the needs. – ZER0 Mar 06 '13 at 00:51
  • Yeah, the fact that you mentioned a bootstrap file is why I think this is the best answer. – Ben Lee Mar 06 '13 at 00:52
1

As a rule, I go with as few as possible simply to reduce the number of requests made to the server.

iGanja
  • 2,374
  • 2
  • 28
  • 32
0

As suggested it is nice to work with smaller files, but for production code, your build process should include optimization. Part of that optimization should be minimizing the file sizes and network traffic optimzation, by combining into a single js file to reduce calls made by the browser.

Gerard Sexton
  • 3,114
  • 27
  • 36
0

Depends on the size of your application. But typically always better to group your javascript files appropriately for better maintainability and re-usability.

You could use a JS module loader like RequireJS to load your JavaScript. At least the files will be organized. You can enhance server performance by making sure these files can be cached on the user's browsers so that they only download them once.

Amy
  • 7,388
  • 2
  • 20
  • 31