Why place all of your Javascript code in one file? Is it possible and is it make sense to split into smaller logical file units?
With only one JS file you would get less HTTP header overhead. In regards to web development: you have to fit your target audience. Web traffic is expensive, so you must minimize the web traffic and maximize the message.
You can place Javascript in as many files as you want, but the only way to communicate between files is with global variables, so it is best to keep things contained, with as limited a global "surface area" as possible.
This is just a historical consequence of how the language was designed.
You can have two different "builds" of the JS code. One nice, modular version that you write, then use Google's JS compiler to build a fast, optimized, small version for live use.
Yep. Looking at the source to this page alone, I see at least four javascript files referenced, plus an inline script element on the page itself.
You should split up your files however you think it's appropriate. Most of the time you'll have a library of related classes and methods all in one file, or maybe in separate files that can be included by calling an intermediate file that's responsible for, in turn, including all the others. Logical grouping is key.
On the other hand, when you run a site like SO, there are other things to take into account - if you put all your javascript in separate files, that's at least four (for this page) separate requests to the server (or to several servers) to load the page, which could mean gigabytes of bandwidth just in additional HTTP headers if you run a popular site, and might be a compelling reason to consolidate your javascript files. Not many people have to worry about that, but it pays to think about these things.
JavaScript and CSS files are often combined into one file (each) so that the browser makes less requests to the server.
Browsers can generally only make 2 concurrent connections to a web server, so if files can be combined into a single stream you will get much better perceived performance in the browser, as more data can be downloaded in a single connection.
This is the same idea behind image sprites, where multiple images are put into a single, large sprite file that is downloaded once, then 'masked' using CSS and background images to show the image you are interested in.
In practice, you should have separate files in development, and run a combiner / compression utility as part of your deployment process that combines and compresses (if appropriate) the JavaScript and CSS resources into single files.
It always makes logical sense while development to work on separate files. But when the JS files are being included in the HTML, a separate download request for each JS file is made. I'd recommend working on separate files, but collating (and compressing) all of them at compile time before including in the archive.
Because HTTP is stateless protocol and in web application every page has its own identity means we cant create object of other page. and javascript is client side language which runs in browser with HTML. i think thats why its not support multi file concept
Best practice is still to minify the JS file and deliver it with at least the ETag
, Last-Modified
and Expires
headers and if applicable also gzip it.
We use YUICompressor to minify and merge all relevant JS files into a single file with all functions which applies on the requested page(s). The same is done with CSS files.
I don't know what server-side programming language you're using, but if it is Java/JSP, then you may find this article useful as well. Otherwise the YSlow Firebug addon may give a lot new insights.