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.
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.
Comments
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.