Webpacker: What's the benefit of Webpacker?

[AndrewRayCode]

Feel free to close this ticket. I'm not sure where a good forum is for this question (I asked in #rubyonrails IRC but didn't get a satisfactory answer).

I'm trying to understand the benefit of Webpacker VS managing static assets with vanilla Webpack entirely outside of Rails.

I have a SPA with a thin Rails server (just passes a few variables to the view to inject in the Javascript React app). I do almost no Rails view/controller work. I'm trying to understand if Webpacker gives me any benefits, or if it's better to manage dependencies entirely in Webpack and don't let Rails touch them.

Here's what I think are benefits of Webpacker:

• I get automatic deploys and configuration, loading hashed file names via javascript_include_tag
• I get automatic asset compilation since Webpacker hooks into Rails tasks
• If not using hot reloading, don't have to run Webpack as a separate process in development

And the downsides of Webpacker?:

• Adds a layer of indirection over Webpack. You have to mutate the existing Webpack setup by pushing in to arrays, there are non-standard configs like config/webpacker.yml, Webpacker::Compiler.watched_paths, you run Webpack _through_ ruby (ruby ./bin/webpack-dev-server), packs/ directory...
• Hot reloading (default development Webpack setup) has issues in Webpacker?
• You still have to run a separate process if you want the Webpack dev server (which is standard for local Webpack development)?
• Even though this is supposed to replace the rails asset pipeline (good), assets are still served through the rails server locally by default, in the end it's shipping the manifest to sprockets to do _____ with it? So it's still coupled to rails / the asset pipeline? This is part of my confusion - Webpacker seems to couple into Rails, but also claims to escape the asset pipeline?

If I have zero Rails view code, zero vanila asset pipeline assets, a bare bones controller, and all of my application generated via Javascript, and I don't use react-on-rails do I get a benefit from Webpacker? Or am I better off running a vanilla modern Webpack setup and adding some manual glue to load the dev server URL locally, and a hashed filename in production deploys, and hook into asset compilation to build assets with a regular Webpack command?

When I try to understand a new technology, I find it helpful to learn when not to use it. Is my case when I should not use Webpacker? Are there benefits I'm overlooking? Are there downsides I'm overlooking? Is the answer to this ticket "go read the docs?"

[guilleiguaran]

Even though this is supposed to replace the rails asset pipeline (good), assets are still served through the rails server locally by default, in the end it's shipping the manifest to sprockets to do _____ with it? So it's still coupled to rails / the asset pipeline? This is part of my confusion - Webpacker seems to couple into Rails, but also claims to escape the asset pipeline?

Webpacker doesn't depend on Sprockets or use it, you can use Webpacker in an app without Sprockets

[paneq]

@AndrewRayCode If all your frontend is generated by Javascript then probably not much benefits. But if part of your frontend is rendered by rails and you have some interactive components added to it then it is nice to use Rails helpers to add the proper javascript tags in a template.

[gauravtiwari]

Is my case when I should not use Webpacker?

If you are not using Rails and Webpack for modern JS.

If I have zero Rails view code, zero vanilla asset pipeline assets, a bare-bones controller, and all of my application generated via Javascript, and I don't use react-on-rails do I get a benefit from Webpacker?

Webpacker out of the box comes with production ready webpack configs that you don't have to touch in most cases. I understand config/webpacker.yml is an extra layer but it's really small and cares all about setting paths, which saves you from writing ton of boilerplate code.

Webpacker is an ideal choice because you don't have to do all this 😄

Or am I better off running a vanilla modern Webpack setup and adding some manual glue to load the dev server URL locally, and a hashed filename in production deploys, and hook into asset compilation to build assets with a regular Webpack command?

_just kidding_

But the most important benefit that we often overlook is our happiness and experience as programmers. If things are integrated and part of one workflow, then it leads to better and happy work. I guess that's what been the mantra of Rails stack - to provide integrated systems that work together. Obviously, things aren't 100% but we are working towards making Webpacker better and integrated, just like asset pipeline and you can contribute too 🎉

I have recently published this example: https://github.com/gauravtiwari/webpacker-api-frontend, which is basically Rails API and JS frontend. In production, you can use nginx or similar to serve static assets from public/packs directory.

Obviously, it's your choice in the end ^_^

[guilleiguaran]

We have some good answers already so I'm closing this 😊