Tuesday, March 3rd, 2009
Juicer: Package your JavaScript and CSS
Category: Performance
, Utility
Christian Johansen has released Juicer a very nice Sprocket-esque tool for packaging and managing your JavaScript AND your CSS.
It has taken all of the best practices and put them in one tool, including:
- resolve dependencies for JavaScripts and CSS files
- combine files
- add cache busters to URLs inside CSS files
- cycle asset hosts for URLs in CSS files
- minify files (currently only with YUI Compressor, later others as well)
- check syntax of JavaScripts with JsLint before they're minifyed
The cache buster feature is quite cool. Take a look at the output of these commands:
CSS:
-
-
$ juicer merge file.css
-
body {
-
background: url(../images/bodybg.png?jcb=1234567890);
-
}
-
-
$ juicer merge -c hard file.css
-
body {
-
background: url(../images/bodybg-1234567890.png);
-
}
-
4.1 rating from 16 votes
What is the use of this cache buster?
The cache buster is needed when you use a far future expires header to enforce client side caching of static assets. It’s a recommendation from the YUI team (check out the rational behind YSlow). I gave the background for the expires header and cache busters in a previous post.
Christian
Java users can resort to Jawr for identical purposes plus several goodies such as i18n javascript or Grails integration.
Wow, that looks very interesting. Am definately going to take it for a spin soonish.
You shouldn’t use querystrings to bust the cache: Revving Filenames: don’t use querystring. Proxies, including Squid, won’t cache resources with a querystring.
@souders: This is why Juicer offers the –cache-buster=hard option, which generates URLs like myimage-1234567890.png (from myimage.png). This requires either file renaming or web server rewrite rules though, as outlined in my original post on the far future expires header. But I learnt this stuff from you, so you probably know already :)
I am dreaming of some kind of apache mod or framework indipendent (?) Framework for packing inline css and javascript on the fly.
@Aimos: Plan is to distribute Juicer as a framework independent tool. My first idea was to package it as a standalone tool (ie with embedded Ruby). Other ideas include making some web app/tool to serve files regardless of which framework you use. Any ideas in this direction would be much appreciated!
Hi, we did something similar with Loom so I followed this news item with curiosity. We arrived to similar conclusions, only that instead of using the last modification date we are using the MD5 hash, which gives less false negatives (actually, if I just save the file without any modifications it will get downloaded again). The idea is not mine, it’s just how GWT works. The concept can be tested here, check out the CSS, images and javascript files.
About the multiple “Asset hosts”, you should be checking that the same host is generated for the same resource, each and every time – otherwise, the same resource may be downloaded twice.
These are just random thoughts that I thought were worth sharing. That being said, I like some of the ideas of Juicer, such as the @import and @depend annotations. Good stuff!
icoloma: the MD5 hash idea is pretty interesting, especially where VCS modify mtime without the file being modified. I’ll consider it for sure.
About the asset hosts: If you give Juicer a spin. you’ll be pleased to note that any image will always be served from the same host when cycling several hosts. If you’ve already tried Juicer and found this not to be true, please let me know – then it’s a bug. But I do think it’s working OK :)