What does the Asset Pipeline actually do?

The asset pipeline was introduced in Rails 3.1 (I believe) and has been a controversial addition ever since. I’ve gone through stages of hating it and stages of wondering how I ever managed without it.

The biggest initial problem with it is that it’s just confusing till you get your head around what’s going on.

You put your javascript in app/assets/javascripts but you reference it in /assets?

Why can’t you find that image?

Where did that font go?

The asset pipeline is a pre-processor for your assets. What lives in app/assets gets compiled – either on the fly in development mode or on deployment (usually) in production mode. And it’s in production mode where it really shines.

Because what the asset pipeline does is squash your assets into the smallest possible packages – a single JS file for your javascript, a single CSS file for your stylesheets (using application.js or application.css as a manifest to tell it which files and folders to include). And then it fingerprints each file, adding a digest to the filenames; you configure your web-server to serve these assets with an infinite cache time, your browser loads /assets/application-abc123.js and then caches it for ever more. Instead of loading 30 separate JS files every time a page loads, it loads a single file and then never asks for it again. The same applies to your CSS file. And while images and fonts aren’t squashed together, the same fingerprinting means they too can be cached. All of which makes your pages load faster.

The clever bit comes when a file has changed. When the assets are compiled, this changes the digest on the filename. So while your browser previously loads /assets/application-abc123.js and cached it, now it’s being instructed to load /assets/application-def456.js – a file which it’s never seen before, so it downloads it and caches that one for the future too.

So that’s the assets side of things. What about the pipeline?

Well, it effectively uses file extensions to figure out how to deal with a file. If you have a file called styles.css.scss the pipeline looks at it, realises it’s a SCSS file and then compiles it to a CSS file for you. If it were called styles.css.scss.erb it would process it as an ERB template first, then convert it to CSS. The same applies for javascript – your documents.js.coffee file will get translated from Coffeescript to Javascript for you. In development mode this happens on the fly, in production mode it happens once during the compile stage, which is normally during deployment.

Because of all this file mangling, you can no longer rely on hardcoded paths to your asset files. So instead, Rails offers a load of asset-pipeline-aware helper methods – stylesheet_link_tag, javascript_include_tag, image_path and font_path.

So there you have it – at first it looks confusing and it can be annoying at times, but the asset pipeline makes a real difference to your apps when they’re live so should be embraced whenever possible.

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe