From the webpacker gem:

Webpacker makes it easy to use the JavaScript pre-processor and bundler Webpack 2.x.x+ to manage application-like JavaScript in Rails. It coexists with the asset pipeline, as the primary purpose for Webpack is app-like JavaScript, not images, CSS, or even JavaScript Sprinkles (that all continues to live in app/assets).

However, it is possible to use Webpacker for CSS, images and fonts assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks.

Why is it more relevant for component-base frameworks to use Webpacker for assets? If I'm using React, what difference does it make to get assets from asset pipepline vs Webpack?

From the webpacker gem:

Webpacker makes it easy to use the JavaScript pre-processor and bundler Webpack 2.x.x+ to manage application-like JavaScript in Rails. It coexists with the asset pipeline, as the primary purpose for Webpack is app-like JavaScript, not images, CSS, or even JavaScript Sprinkles (that all continues to live in app/assets).

However, it is possible to use Webpacker for CSS, images and fonts assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks.

Why is it more relevant for component-base frameworks to use Webpacker for assets? If I'm using React, what difference does it make to get assets from asset pipepline vs Webpack?

• javascript
• ruby-on-rails
• reactjs
• webpack
• asset-pipeline

1 Answer 1

In terms of strictly holding assets - I don't think there's too much difference. However, I've recently migrated one of our apps from the asset pipeline to webpack - I will try share some learnings of why webpack is beneficial below.

• Despite Rails being a fast moving and dynamic web framework, using the newest front-end tools with the default rails assets handler is difficult. Managing JS libraries with bundler is a pain. Webpack makes maintaining 3rd party libraries considerably easier.
• Page loads using webpack were faster with webpack than the default asset pipeline considering it compiled files by default during each refresh.
• Rails directory structure doesn't distinguish clearly enough between the front-end and back-end of the application. The dawn of single page applications has meant that identifying the client-side of an app as a separate entity and not some addon to the back-end is something we viewed as quite important. Front end components are not just addons. They are their own beings.
• Separating assets from views is strange - views and assets create one being and should sit in one place, Rails views are treated more like a backpack on the controller.
• Hot-reloading of our app front-end is great. This saves a lot of time in development.

However

• we've found that it can be volatile with constant configuration changes and unfriendly as a result.
• It doesn't run automatically on a request, like something like sprockets does. For example, if you are using webpacker, You need to have the webpacker dev server running that first looks for file changes, then compiles, and only then may reload your page.

The fact that webpack is primarily concerned with js and not jpegs, pngs, svgs etc. makes comparing the rails asset pipeline and webpack a little confusing...

Not sure if it did, but I hope this helps!