request: discussion of webpack vs asset pipeline

[mustmodify]

trafficstars

Help us help you! Please choose one:

• [ ] My app crashes with react-rails, so I've included the stack trace and the exact steps which make it crash.
• [ ] My app doesn't crash, but I'm getting unexpected behavior. So, I've described the unexpected behavior and suggested a new behavior.
• [ ] I'm trying to use react-rails with another library, but I'm having trouble. I've described my JavaScript management setup (eg, Sprockets, Webpack...), how I'm trying to use this other library, and why it's not working.
• [x] I have another issue to discuss.

---

As someone who is trying to get started using this gem, I'm asking whether you would be willing to include a discussion of the tradoffs between using webpack and asset pipeline either in your readme or linked from there. I know I feel like that's a decision I'm making without understanding it, and I'm sure others do, too.

Thanks for your consideration.

[mustmodify]

It seems like, with asset pipeline, you would be dependent on gemified assets for things like thunk, whereas with webpacker you'd have access to npm... but I may not understand that well enough.

[BookOfGreg]

Hi, @mustmodify,

Good question. Not sure how others feels but personally I believe that Webpacker and Webpack itself is the future of JS on large Rails apps. You're spot on about access to NPM, and it's doubly true if JS is a large part of your application.

There will be tons of people out there using Sprockets as their asset pipeline and frankly I prefer Sprockets myself for small apps or when I'm starting out, then when a team of front end devs come onboard it gets swapped to Webpack, especially now it's won out over the alternatives like Browserify.

What topics would you think would make a useful concise discussion point in an intro in the readme, I suspect Rails devs finding their way here will already have some awareness of JS ecosystem if they come seeking native React integration.

Fun little note, I'd forked this gem a year ago and converted it to Gulp/Grunt + Browserify for it's pipeline before Webpacker was even a thing, turned into a total mess! Glad Webacker has the ecosystem behind it now and us Rails devs can keep being super productive. Writing this late at night so apologies for babbling 😁

[rmosolgo]

converted it to Gulp/Grunt + Browserify

🍻 that's awesome! I'm glad to see a "blessed path" for Rails, too.

[mustmodify]

Hi @BookOfGreg -- thanks for your generous response.

You said:

I suspect Rails devs finding their way here will already have some awareness of JS ecosystem if they come seeking native React integration.

I guess that's true. I have "some awareness" of it. But what I said about npm, for example, was a complete guess. So my principle question is "Assume I know not-very-much. How will this decision change my life in dev and in production?" Some thoughts:

• The thing I mentioned about NPM vs gems.
• I believe that webpack and sprockets both concatenate all js files into one... if that's true, I would say that. And I assume it also does minification and compression?
• Will webpacker do fingerprints like asset pipeline?
• But WebPacker isn't what turns ES6 code into "acceptable" javascript, right? That's another tool often bundled with it... So is that available either way?
• Will I need to commit a webpacker asset file to the repo? Or will it be generated during precompile? If so, is that handled for me, or do I need to add something to capistrano / etc?
• With the react_on_rails gem I needed to have a separate process watching webpacker. But I don't need that for the asset pipeline. Is that true here? How should I set that up?

[BookOfGreg]

That's a good series of points. Thanks for your time in making such a handy list.

@mustmodify Do you reckon this would be well served by a wiki entry linked from the Readme or some other extra material? I'm thinking the readme, docs, examples could do with a general tidy up as a couple folk have mentioned to me separately they aren't reading well top to bottom.

@rmosolgo Mind if I try reworking a lot of the docs around this, incorporating the points above as talking points in a wiki? Have any structural thoughts on it yourself?

[mustmodify]

Wiki would be fine, though I would probably just put it in docs/webpack-vs-asset-pipeline.markdown or something like that. I don't like linking to something that isn't in the repo. YMMV.

[mustmodify]

My principle question above could perhaps be better stated this way:

"I use Rails. I like the asset pipeline. It provides all kind of production goodness. I'm at peace with adding js to my app because client-side code is good. But why would I consider going outside the asset pipeline? Not only that, but I'm moving only part of my assets outside it!"

PS bonus points for figuring out how to get webpacker to work while files are at app/assets/javascript. :)

[BookOfGreg]

The p.s isn't too hard :)

config/webpack.yml

default: &default
  source_path: app/assets/javascript

[mustmodify]

Won't you end up with webpack compiling the same assets as the asset pipeline? how will this work with rake assets:precompile? I guess that's an issue for another ticket. :)

[BookOfGreg]

Webpack will only compile things linked from the entries, and only the extensions listed in extensions, so you should be able to filter out most of the stuff in there.

[BookOfGreg]

@mustmodify I've made a Wiki article here, not totally happy with it yet but it's a start. There's a fair amount of content on the subject already so a section of links might help the article. I was hoping you might be able to help with some of the content there, you should be able to edit it.

[mustmodify]

Good start!

I started to write stuff, erased it, started to write again, erased it ... I'm not happy with my ideas for this. I'm getting that same feeling I have when code needs to be refactored. Let me think about it a bit.

[hopewise]

As for my experience, I found that its better to run production pre-compile locally rather than at server when using react-rails gem, as it will result into building fresh packages at the server and thus using high resource from CPU while building..

how would I prevent react-rails gem from participate with rake assets:precompile ?

[alkesh26]

@BookOfGreg had documented the Webpack vs Sprockets here. Closing the issue.