Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

request: discussion of webpack vs asset pipeline #813

Closed
1 of 4 tasks
mustmodify opened this issue Oct 23, 2017 · 14 comments
Closed
1 of 4 tasks

request: discussion of webpack vs asset pipeline #813

mustmodify opened this issue Oct 23, 2017 · 14 comments
Assignees

Comments

@mustmodify
Copy link

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.
  • 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
Copy link
Author

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
Copy link
Member

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
Copy link
Member

converted it to Gulp/Grunt + Browserify

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

@mustmodify
Copy link
Author

mustmodify commented Oct 24, 2017

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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

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
Copy link
Member

The p.s isn't too hard :)

config/webpack.yml

default: &default
  source_path: app/assets/javascript

@mustmodify
Copy link
Author

mustmodify commented Oct 25, 2017

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
Copy link
Member

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.

@mustmodify mustmodify mentioned this issue Oct 25, 2017
4 tasks
@BookOfGreg BookOfGreg self-assigned this Nov 3, 2017
@BookOfGreg BookOfGreg added this to the 2.4.1 milestone Nov 3, 2017
@BookOfGreg
Copy link
Member

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

@BookOfGreg BookOfGreg removed this from the 2.4.1 milestone Nov 6, 2017
@mustmodify
Copy link
Author

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
Copy link

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
Copy link
Collaborator

alkesh26 commented Nov 2, 2022

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

@alkesh26 alkesh26 closed this as completed Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants