5 ms·

Sprockets 2.0.0 released (Ruby/Rack asset packaging)

39 points by sstephenson 15y ago

sstephenson 15y ago
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 http://news.ycombinator.com/item?id=487601 Some alternatives include the very popular Jammit from DocumentCloud (http://documentcloud.github.com/jammit/ http://documentcloud.github.com/jammit/), Alex MacCaw's Ruby port of Stitch (https://github.com/maccman/stitch-rb https://github.com/maccman/stitch-rb), and Mislav Marohnić's "poor man's Sprockets" (https://twitter.com/#!/mislav/status/87899513649496065 https://twitter.com/#!/mislav/status/87899513649496065).
socratic 15y ago
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 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?
- riffraff 15y ago
  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.
- rubymaverick 15y ago
  Check out the Ruby on Rails guide on the subject: http://ryanbigg.com/guides/asset_pipeline.html 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-railsconf-2011-right-here-right-now-4769.html http://www.rubyinside.com/dhh-keynote-streaming-live-from-ra...
- tenderlove 15y ago
  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.
  - jashkenas 15y ago
    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?
    - tenderlove 15y ago
      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.

39 points by sstephenson 15y ago

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 http://news.ycombinator.com/item?id=487601 Some alternatives include the very popular Jammit from DocumentCloud (http://documentcloud.github.com/jammit/ http://documentcloud.github.com/jammit/), Alex MacCaw's Ruby port of Stitch (https://github.com/maccman/stitch-rb https://github.com/maccman/stitch-rb), and Mislav Marohnić's "poor man's Sprockets" (https://twitter.com/#!/mislav/status/87899513649496065 https://twitter.com/#!/mislav/status/87899513649496065).

socratic 15y ago

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 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?

riffraff 15y ago
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.
rubymaverick 15y ago
Check out the Ruby on Rails guide on the subject: http://ryanbigg.com/guides/asset_pipeline.html 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-railsconf-2011-right-here-right-now-4769.html http://www.rubyinside.com/dhh-keynote-streaming-live-from-ra...
tenderlove 15y ago
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.
- jashkenas 15y ago
  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?
  - tenderlove 15y ago
    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.