I <3 the Asset Pipeline

i_heart_asset_pipeline.md

I <3 the Asset Pipeline

People talk shit on Sprockets and the Asset Pipeline all the time. I get it. It's pretty confusing and when it breaks it can break in really undesirable ways. I was originally very sceptical, and I strongly considered upgrading to Rails 3.2 with sprockets disabled.

I didn't, and I'm glad I've stuck with the pipeline. Here's why:

1. If you're using digested assets (by default you are), asset expiry just works. No cache clearing during dev, no "wait a few minutes for the CSS to expire", no expiring every asset on every deploy, no deployment issues where people get new HTML and old CSS or JS. Sprocket's digest strategy has so far been excellent and I'm glad it's there.

2. SASS and CoffeeScript just work. No running guard or compass to watch and auto-compile your shit, relatively seamless integration into Rails, and effective separation of vendored code from application code.

3. There's One Way To Do It. This is driven mainly by the above point, but I remember having one method for generating CSS from SASS, another for determining my cache-buster query string, and another for combining and minifying multiple Javascript files. The unification of these into one provider makes it easier for the community to collectively recognize, understand and overcome issues. It also decreases the amount of boilerplate code significantly.

4. Effective separation of application assets from 'dumb' files. If something is in app/assets it means it is part of my application, might be compiled, and will change along with my application. It's a semantic point, but I think it's an important one.

Out of curiosity, how are you dealing with calls to asset_{path,url} in your javascript? Plain old .js.erb? I am finding it ridiculously stupid to write my javascript in erb, especially knowing I want to move to haml in the near future.

@tigris I'm not. Most of our JS is legacy (and thus references stuff still in /public), new JS will use data attributes, so the HAML (or Json from the controller) gets to use the path helpers.

I personally think that ERB-all-the-things is pretty terrible and I will go to some lengths to not use it.

@tigris Also - some vendored javascript that references image files I keep in public/vendor rather than app/assets. Eg CKEditor.

Completely agree. ERB everything is a horrible idea. data attributes is the only logical solution i've seen so far but requires "re-writing" all my legacy prototype js, which I want to move to jquery anyway so it's basically forcing a bunch of refactoring on me. I don't get why someone hasn't written some kind of JSON manifest for the assets and then some nice rails-jquery or rails-prototype style methods that hook into the manifest.

@tigris ooooh, that's clever, and that'd be pretty easy to do too. You could do it in a couple of lines: injest manifest.yml, emit as json, bam.

create a kickstarter project for it, i'll donate $1... that's the done thing for rails / opensource now isn't it?