Sprockets 2.0.0 released (Ruby/Rack asset packaging) | Hacker News Reader

Sprockets 2.0.0 released (Ruby/Rack asset packaging)

github.com

39 pointssstephenson7 comments

Sprockets provides the basis for Rails 3.1's asset pipeline.

For a look back in time, see the Hacker News thread for Sprockets 1.0, from two and a half years ago: http://news.ycombinator.com/item?id=487601

Some alternatives include the very popular Jammit from DocumentCloud (http://documentcloud.github.com/jammit/), Alex MacCaw's Ruby port of Stitch (https://github.com/maccman/stitch-rb), and Mislav Marohnić's "poor man's Sprockets" (https://twitter.com/#!/mislav/status/87899513649496065).

Is there somewhere that gives a good description of the current state of asset packaging in Rails? Personally, I find the whole thing really confusing.

Right now, I'm just using asset_id (https://github.com/moocode/asset_id) to dump my assets on S3/CloudFront with md5s in the filenames, pretending to myself that that will make everything fast.

It seems like all the gems provide different things, whether it's CSS minification, JS minification, includes to combine many files together, automatic aggregation of multiple JS/CSS files, CSS sprites, easy uploading to CDNs, different strategies for cache busting (md5 of file vs node timestamp)...

I'm presuming that with Rails 3.1, everyone is going to switch over to Sprockets 2.0 from Jammit (which is what it seemed like everyone used before). However, I honestly have no idea what's going on or where the big wins are.

What's up?

I second the question. FWIW the current deploy procedure I use for $job (written by a colleague) is an unholy mix of jammit, spritemapper, rake, %x{git} and asset_id.

It _does_ work, but I am quite looking forward to the integration of rails 3.1 to get rid of it.

Check out the Ruby on Rails guide on the subject:

http://ryanbigg.com/guides/asset_pipeline.html

DHH also talked a lot about it in his keynote this year at RailsConf:

http://www.rubyinside.com/dhh-keynote-streaming-live-from-ra...

I think it's unlikely that many people will switch from Jammit to Sprockets. At work, we will not switch. Sprockets is built on the assumption that you will be running a JavaScript runtime on your production machines. I'd prefer that we (the rails team) had a solution that didn't make such an assumption. That way the solution could work with or without a JS runtime in production.

Out of curiosity, is there anything in Sprockets 2.0 that's enticing you towards switching over -- apart from being the Rails 3.1 default?

Well, we don't have a JS runtime on all our web boxes in production. As such, we precompile all our assets before deploying, so sprockets doesn't really buy us much besides being "baked in". To migrate our apps, it seems easier to upgrade rails, but continue to use our current asset compilation system.

Reply on news.ycombinator.com