Skip to content

Choosing Sprockets or Webpacker

Greg Myers edited this page Nov 6, 2017 · 2 revisions

Based on discussion in #813

Below are some simplified discussion points about Sprockets VS Webpacker.

In general I believe the community is moving towards Webpacker over time, especially for larger apps and teams. It's easily possible however to have only JS in Webpacker and CSS+Images in Sprockets with no issue. I'd not recommend having components split between Sprockets and Webpacker if any component one one side references one on the other.

Why would I choose the default Asset Pipeline, Sprockets?

  • If I have a simple rails app
  • If I have a large legacy app that will cost much to migrate
  • I want to make use of gems that require sprockets

Why would I not choose Sprockets

  • If I need to modify my build process
  • If I need to use node packages that are not common enough to be 'gemified' or simple enough to be included as vendored JS

Why would I choose Webpacker

  • If I need to use node packages
  • If I want to build Single Page Apps
  • If I would prefer to modify my asset build process in the same language I build it
  • If I have assets outside of Rails
  • If I want the latest ES6 or Babel features

Why would I not choose Webpacker

  • If I have a simple rails app that does not need advanced JS features
  • If I am a backend developer with limited knowledge of JS ecosystem

Similarities

Both Sprockets and Webpacker will:

  • minify and digest(fingerprint) assets when building for production.
  • compile the assets in packs(webpack) or the named assets(sprockets) into large bundles for production.
  • incrementally rebuild files in dev as you change them.