What's the advantage of using this gem over rails' new webpacker gem?

[gnapse]

Correct me if I'm wrong, but the new rails/webpacker gem provides the same capability to a rails app as this gem does. What are the pros and cons of each approach?

[gotoAndBliss]

For me.. Rails < 4.2 support..

[cymen]

@gnapse I contributed extensively to this gem so that we could use it in the past to get off of the Rails asset pipeline. So I think it's ideal for getting legacy JavaScript off of the Rails asset pipeline by allowing you to rewrite it to CommonJS and then jumping off to running say webpack directly (say via Foreman and a Procfile).

My two cents is that the Rails asset pipeline is a huge impediment to best practices in the JavaScript world. It's been that way for a long time and only now getting slightly better.

But it depends if you want the magic of lots of Railsy helpers. Or if you want conventional modern JavaScript. I'm solidly in the second camp.

The reality though is you are definitely free to use it as you see fit and we seem to have a number of different use cases. But if you're starting a new Rails project, I wouldn't recommend using this. I would either go to the direct webpack/browserify route or go to whatever the hot Railsy thing is on the Rails side.

[cymen]

That said, I checked out rails/webpacker and it looks good. That is a huge step in the right direction for Rails and the RoR community. That would be the first thing I'd try if I was starting a new RoR today.

[cymen]

I updated the README with my opinionated take on this here:

https://github.com/browserify-rails/browserify-rails#should-you-use-this-gem

Thanks for bringing rails/webpacker to my attention.

[gnapse]

Yes, and just to clarify, rails/webpacker also enables you to avoid the asset pipeline. It is not another way of using the pipeline. It pretty much does what this gem does, but in a different way.