This question already has answers here:
Put javascript in one .js file or break it out into multiple .js files?
(11 answers)
Should I copy all my JavaScript sources into one single file?
(3 answers)
Closed 9 years ago.
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.
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:
Core file. Contains functions that are used almost everywhere and other useful page initialisation things.
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.
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.
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
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!
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.
As a rule, I go with as few as possible simply to reduce the number of requests made to the server.
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.
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.
Related
I have a web application that is currently split into like 40+ javascript files. When I run the application some subset of those files need to be downloaded by the browser. Obviously, given that browsers use ~6 threads to download files, this is not the optimal solution. One optimization idea that come to my mind was to embed all those javascript files (except external ones) inside the served .aspx page. So that the browser just gets one big html file and does not need to make any round trips to the server. The html page alone may contain user specific data that will be different on every request. The scripts, however, are not changing between requests. In typical use case the page (complete with scripts) has 180KB (scripts not minified) or 130KB (minified).
Now the question: does this approach have any drawbacks performance wise (network, browsers' javascript engines)? Do you know of any big applications doing something like that? Note that I am not interested in arguments about eg. maintainability as the individual scripts will still be available as separate files during development. Same question applies to css files (even though this is less of an issue in my app).
One bit of information that may be important here: the application is one big multipage form that does not require postbacks to go between the pages, validate form, submit the form, etc. However, the application in which it is embedded may have multiple such forms.
In general, it is a very good idea to concatenate javascript and css files together. I'm just not so sure about "your concept". My biggest concern and question here would be, can that .aspx file change potentially in any way through (dynamic) code ?
That would make in impossible for the browser to cache the file, which would be a horrible scenario.
The great thing about concatenating files is, that we have one big downstream (which still is a lot faster then downloading with several single requests and HTTP overhead) and the browser can cache this file afterwards.
There are some great build-tools and scripts available, Apache ANT is one I can really suggest. You should have a look on the HTML5 Boilerplate where they make usage of ANT very frequently.
What is the simplest way to combine JavaScript files into a single file in a Django project?
Explanation
I want this to work with Ember.js/Backbone where you (usually) have many different JavaScript in multiple directories. Directories would all be in one folder called app/ for example, like: app/views/ app/models/ /app/routers/
Requirements
Work together with the staticfiles app
Still be separated while in development mode for easier debugging (only compile when calling collectstatic?)
Work with Require.js (guess that shouldn't be too hard, but putting it in here to be sure)
Extra credit
Explain a best practices way of combining Django and Ember/Backbone.
I am an happy user of django compressor, it does combine, minify, debug-friendly, you can use it with staticfiles, easy to plug with custom storage backend (eg. S3)
https://github.com/jezdez/django_compressor
The reason you want to combine many files into one is so to minimize latency of setting up and tearing down http requests, the fewer you make the better. However, many newer browsers are downloading JavaScript files in parallel (still executing sequentially). The consequence is that downloading a single 1Mb file may be slower than three 350Kb files.
you can use from CDNs.
As mentioned in the previous answer, django-compressor is nice, but you often get better loading times when using a dedicated javascript loader instead. My tip is to check out Head.js for example (http://headjs.com/) (there are tons other out there as well). Often combining scripts can be contra productive when considering caching, using javascript located on CDN:s etc.
One thing to remember is that Iphone 3/4 will just cache 15/25KB of javascript, so if you have huge scripts and combine them you can run into trouble. http://www.phpied.com/iphone-caching/
Is there a good rule of thumb as to how big (in size) a JS file should be - that if it grows bigger than this it's good idea to split it into smaller files?
The same size as any other languages (never more than a few hundred lines), and the concat and minify at runtime (using the Closure compiler or the Yahoo libs or whatnot) is what we do.
More files = More HTTP Requests = Slower website
Develop in as many files as you want. Organize your code to keep development manageable.
Then, when you deploy, ship a minified/combined version of the code using a tool like Google Closure
This is what jQuery does. They ship one file, but the actual source code is much more organized.
Less files = less clean code = slower coding.
Cost more than bandwidth.
Edit: if you really want to, you may have tool to merge them after you code of course.
All my JS files - one per function plus the libraries - are in one folder outside the public directory, the prioritary ones start with one or two underscores. In my index page, a PHP script from a static server is called. It checks whether or not the compressed JS file exists. If it does not, a scandir is performed on the JS directory, and each file is included in a buffer, then compressed, and put into a single file. And it outputs the content of this file.
If I change/add/delete a js file, all I have to do is delete the compressed file, and it will be recreated at the next load.
The advantage here is that you have a single and optimized http request for the javascript, and still you can divide your scripts in as many files as you wish. The file creation process - which can be heavy - is not used each time the page loads but only when the file is missing. This method is good when like me you use it with an application which never reloads, or doesn't need to load specific functions for specific pages, although there would be plenty of workarounds.
Our file structures is pretty good, organizing functionality in separate folders. My question is how do others work on applications that involves upwards of 500 JavaScript files.
We have written a maven plugin to concatenate these files together (also runs YUI compressor). However, this involves 3-10seconds of compiling for every change.
Is this step necessary for organization of a large application, I feel like a well structured HTML file pulling in all these resources would save me 45minutes every day.
For my own framework projects, typically monitoring, testing, or in-page services to orchestrate other toolkits (but not as high as your file count), my approach has been to target the individual and dynamically loaded files during development. For test, I'll run one build to compress and version the individual files, and test the individual files again because, depending on the concatenation order, compression technique, and browser, I may wind up with a script error and it's a pain to dig it out of one monster file. Third, I'll concatenate together and test once more.
In the HTML reference, I'll either target the uncompressed file, which loads specified dependencies, or the compound file. A separate bootstrap file names the dependencies, which are either included in the compound file, or loaded dynamically as needed.
This way I can add or change a file, and start developing and testing without rebuilding.
The solution is likely to concatenate and compress for user testing and production only.
For development, it's probably best to simply import them all into the HTML file. It speeds up the dev process, and also simplifies debugging. It also allows the browser to cache some of those files.
When you can't rely on cached copies (which, with 500 files, I don't think will be very often), it will slow down load times.
You can likely save a lot of time by only running the compressor in production. The YUI compressor is notoriously slow, because it uses Java Rhino interpreter to actually parse the JavaScript and analyze it etc.
I've been using yuicompressor.jar on my test server for on-the-fly minimisation of changed JavaScript files. Now that I have deployed the website to the public server, I noticed that the server's policies forbid the use of exec() or its equivalents, so no more java execution for me.
Is there a decent on-the-fly JS compressor implemented in PHP? The only thing resembling this that I was able to find was Minify, but it's more of a full-blown compression solution with cache and everything. I want to keep the files separate and have the minimised files follow my own naming conventions, so Minify is a bit too complex for this purpose.
The tool, like yuicompressor, should be able to take either a filename or JavaScript as input and should either write to a file or output the compressed JavaScript.
EDIT: To clarify, I'm looking for something that does not have to be used as a standalone (i.e. it can be called from a function, rather than sniffing my GET variables). If I just wanted a compressor, Minify would obviously be a good choice.
EDIT2: A lot has changed in the five years since I asked this question. Today I would strongly recommend separating the front-end workflow from the server code. There are plenty of good tools for JS development around and except for the most trivial jQuery enhancements it's a better idea to have a full workflow with automated bundling, testing and linting in place and just deploy the minified bundles rather than the raw files.
Yes there is, it's called minify.
The only thing in to worry about in the way of complexity is setting up a group, and there's really nothing to it. Edit the groupsConfig.php file if you want multiple JS/CSS in one <script> or <link> statement:
return array(
'js-common' => array('//js/jquery/jquery-1.3.2.min.js', '//js/common.js', '//js/visuals.js',
'//js/jquery/facebox.js'),
'css-common' => array('//css/main.css', '//css/layout.css','//css/facebox.css')
);
To include the above 'js-common' group, do this:
<script type="text/javascript" src="/min/g=js-common"></script>
(i know i was looking for the exact same thing not knowing how to deal directly with the jar file using php - that's how i ended up here so i'm sharing what i found)
Minify is a huge library with tons of functionalities. However the minifying part is a very tiny class : http://code.google.com/p/minify/source/browse/trunk/min/lib/Minify/YUICompressor.php
& very very easy to use :
//set the path to the jar file
Minify_YUIcompressor::$jarFile=_ROOT.'libs/java/yuicompressor.jar';
//set the path to a writable temp folder
Minify_YUIcompressor::$tempDir=_ROOT.'temp/';
//minify
$yourcssminified=Minify_YUIcompressor::minifyCss($yourcssstringnotminified,$youroptions)
same process for js, if you need more functionalities just pick from the library & read the source to see how you can make direct call from your app.
I didn't read the question well, since minify is based on using the jar files, the op can't use it anyway with his server config
Minify also include other minifying methods than yui, for example:
http://code.google.com/p/minify/source/browse/trunk/min/lib/JSMinPlus.php?r=443&spec=svn468
Try Lissa:
Lissa is a generic CSS and JavaScript loading utility. Lissa is an extension of the YUI PHP Loader aimed at solving one of the current loader limitations; combo loading. YUI PHP Loader ships with a combo loader that is capable of reducing HTTP requests and increasing performance by outputting all the YUI JavaScript and/or CSS requirements as a single request per resource type. Meaning even if you needed 8 YUI components which ultimately boil down to say 13 files you would still only make 2 HTTP requests; one for the CSS and another for the JavaScript. That's great, but what about custom non-YUI resources. YUI PHP Loader will load them, but it loads them as separate includes and thus they miss out on benefits of the combo service and the number of HTTP requests for the page increases. Lissa works around this limitation by using the YUI PHP Loader to handle the loading and sort of YUI and/or custom resource dependencies and pairs that functional with Minify.