What are the pros and cons of asset_packager and Jammit?

Question

At a glance they seem to be pretty much the same solution to the same problem, but Jammit must have some key difference or improvement that I haven't picked up on, or its author would have just used asset_packager. :-)

Can anyone enlighten me?

Answer 1

Sure. Here's some of the main differences:

• Instead of using simple Ruby-based CSS and JS minifiers, Jammit makes it easy to use either the YUI Compressor or the new Google Closure Compiler to compress your assets.

• Instead of having to specify each file individually, Jammit uses an ordered list of directory globs to define an asset package. This means you can say things like: give me jQuery first, then everything in vendor, then all my models, then all my UI...

    workspace:
      vendor/jquery.js
      vendor/*.js
      models/**/*.js
      view/workspace/*.js

• Jammit supports JavaScript Templates, so whether you're using Prototype or Mustache or Underscore templates, you can maintain your JavaScript views right alongside your Rails views, and have them bundled into a single package, available in the browser.

• Jammit supports image embedding, using Data-URIs for browsers that support them, and MHTML for IE7 and below. Enabling it allows you to embed all of your UI chrome and small icons right into your CSS, so that instead of 50 HTTP requests, your browser makes just one.

• When you install the gem, Jammit includes the jammit command-line utility, which you can use to prebuild all of your assets and pre-gzip them at the highest compression level. Gzipping at --9 gives us about a 30% reduction in size for our assets, over the default gzip --2 (which is closer to what you'll get by default if you're gzipping on-the-fly). You should be using both, but only gzipping on-demand for dynamic requests.

Hope that helps with the differences -- for everything else, there's http://documentcloud.github.com/jammit/