The site I am developing has a large amount of javascript that is shared across various functionality, and an equally large amount of feature-specific javascript. I’ve read all about using one monolithic javascript file vs. many smaller ones.
For my purposes, the huge-file approach would not only result in a script difficult to maintain, but contain a lot of unneeded javascript as well. At the same time, separating the javascript so that only the required code is included would result in an excessive number of files / HTTP requests. The idea of including even a moderate amount of unneeded code seems contrary to the concepts of proper software design, besides the additional file size overhead for the user.
I have found the mod_concat module for Apache which seems like it would solve my problem entirely – I could separate my javascripts into as many files as I want, include only those necessary, and take almost no hit on performance.
Is this actually the case? Is the only potential drawback the need to manage many files? I know mod_concat has not been around forever, so I’m also looking for a bit of background on a) how this was handled before, and b) if, even with code concatenation, including a moderate amount of unneeded javascript is considered acceptable (or even a best practice).
Thanks, Brian
I don’t think you need an apache module for that. Creating one minified JS file for production should be the best way to go, because it is only loaded once and then cached by the browser. Although for development of course, it makes sense to have your application split into separate files.
My personal favorite for JavaScript module management and compression is Steal JS which is part of the great JavaScript MVC framework (could be generally interesting for larger JS applications). It can load module files dynamically during development and for production you can create one compressed JavaScript file (it can do CSS, too).
Another alternative is RequireJS but I only had a quick look at it.