你如何管理你的Javascript文件？

Question

Nowadays, we have tons of Javascript libraries per page in addition to the Javascript files we write ourselves. How do you manage them all? How do you minify them in an organized way?

Answer 1

Organization

All of my scripts are maintained in a directory structure that I follow whenever I work on a site. The directory structure normally goes something like this:

+--root
   |--javascript
      |--lib
         |--prototype.js
         |--scriptaculous
            |--scriptaculous.js
            |--effects.js
            |--..
      |--myOwnScript.js
      |--myOwnScript2.js

If, on the off chance, that I'm working on a team uses an inordinate amount of scripts, then I'll normally create a custom directory in which we'll organize scripts by relationship. This doesn't happen terribly often, though.

Compression

Though there are a lot of different compressors and obfuscators out there, I always come back to YUI Compressor.

Inclusion

Unless a site is using some form of a master page, CMS, or something that dictates what can be included on a page beyond my control, I only included the scripts necessarily for the given page just for the small performance sake. If a page doesn't require any script, there will be no script inclusions on that page.

Answer 2

First of all, YUI Compressor .

Keeping them organized is up to you, but most groups that I've seen have just come up with a convention that makes sense for their application.

It's generally optimal to package up your files in such a way that you have a small handful of packages which can be included on any given page for optimal caching.

You also might consider dividing your javascript up into segments that are easy to share across the team.

Answer 3

Cal Henderson (of Flickr fame) wrote Serving JavaScript Fast a while back. It covers asset delivery, not organization, but it might answer some of your questions.

Here are the bullet points:

• Yes, you ought to concatenate JavaScript files in production to minimize the number of HTTP requests.
• BUT you might not want to concatenate into one giant file; you might want to break it into logical pieces and spread the transfer cost over several pages.
• gzip compression is good, but you shouldn't serve gzipped assets to IE <= 6, so you might also want to minify/compress your JavaScript.

I'll add a few bullet points of my own:

• You ought to come up with a solution that works for both development and production. In development mode, it should pull in extra JavaScript files on demand; in production it should bundle everything ahead of time. Switching from one behavior to the other should be as easy as setting a flag.
• Rails 2.0 handles all this through an asset cache ; other web app frameworks might offer similar solutions.
• As another answer suggests, placing third-party libraries in a lib directory is a good start. You can also divide your own JS files into sub-directories if it makes sense. Ideally, you'll be able to arrange them in such a way that the files in a given sub-directory can be concatenated into one file.

Answer 4

I will have a folder for all javascript, and a sub folder of that for 3rd party/shared libraries, and sub folders for each component of the site to keep everything organized.

For example:

/
+--/javascript/
    +-- lib/
    +-- admin/
    +-- compnent1/
    +-- compnent2/

Then run everything through a minifier/obfuscator during the build process.

Answer 5

I'v been using this lately: http://code.google.com/apis/ajaxlibs/

And then have a "jscripts" folder where I keep my custom code.

Answer 6

In my last project, we had three kinds of JS files, all of them inside a JS folder.

1. Library code . A bunch of functions used on most all of the pages, so they were put together in one or a few files.
2. Classes . These had their own files, organized in folders as needed, but not necessarily so.
3. Ad hoc JS . Code that was specific to that page. These were saved in files that had the same name as the JSP pages they were supposed to run in.

The biggest effort was in having most of the code on the first two kinds, having custom code only know what to call, and when.

Answer 7

This might be a different approach than what you're looking for, but I've been playing around with the idea of JavaScript templates in our blog engine. In a nutshell, you assign a Javascript template to a page id using the database and it will dynamically include and minify all the JavaScript files associated with that template and create a file in a server-side cache with the template id as a file name. When a page is loaded, it calls the template file which first checks if the file exists in the cache and loads it if it does. If it doesn't exist, it creates it on the fly and includes it. I also use the template file to gzip the conglomerate JavaScript file.

The template idea would work well for site-wide JavaScript (like a JavaScript library), but it doesn't cover page-specific JavaScript. However, you can still use the same approach for page specific JavaScript by including a second file that does the same as above.