Consider removing third party integrations out of this gem. about webpacker

[dhh]

We don't have to support every framework under the sun to be helpful. Rails doesn't include drivers for every obscure database but it does for MySQL and PG. Let's follow this pattern here. The majors get just enough to make Hello World possible and that's it. Other gems can expand on that to provide more elaborate support.

…

On Feb 27, 2017, at 17:41, Daniel Leavitt ***@***.***> wrote: So to proceeded, we'd want someone from rails core to create webpacker-react, webpacker-angular and webpacker-vue repos? Our just let people host them outside of Rails for now? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dhh]

We'll have to disagree on this one. Getting you all set for hello world without trawling READMEs and such is a big win in my book. The whole point most people are going to bother with Webpack is to use one of these major frameworks. That should be turn-key easy. I consider it fully within the purview of Webpacker's mandate to provide a basic setup for that. Besides, it's a minimal amount of code. And any changes needed to that code isn't much of an issue either as Webpacker is separate from the Rails gems and can release on its own (and quicker) pace.

…

On Feb 28, 2017, at 13:44, Gaurav Tiwari ***@***.***> wrote: @dhh Absolutely, I see your point, however this isn't the same setup as Rails. Rails, as a web-application framework requires a database by default to work with. It's critical there, however it's not the same relationship here. The analogy would be correct if we go to same length to integrate react or angular in the same way it's with PG or MySQL in Rails. What we are doing currently is running yarn add react react-dom and then generating an example component file. This setup is available all over the internet and anyone who just follows a readme can add it without a problem. That's why I just pointed to perhaps not have it in the first place because it's adds out of context bloat in this gem, which isn't the problem we are truly solving. We can add all these parts in the readme though, which I think is best place for this to go. In regards to an example app, we can create a Vanilla es6 app, that demos most of the fancy stuff used in modern javascript. This will take away a lot of problem from us that we might have to handle if we have this - out of context questions and PR's (add my new fancy framework). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[renchap]

What about the webpacker:install:react (or other framework) Rake task install the webpacker-$framework gem and running a setup task (from the gem) ?
This would allow people to create adapters for other frameworks and move the framework-specific code out of Webpacker. The adapters for the main frameworks could be in the Rails org on GH to provide legitimacy.
This will also ease integration of any future JS framework into Webpacker, anybody can just create a new gem using the same API (well, rake task & naming).

This is only a proposal, I will align with @dhh views here :)

[gauravtiwari]

@dhh Yes, I too see the simplicity of this and as you pointed out it's not a lot of code and I too think it's not as of now, but I am more concerned on the point that community will try to expand this simple setup for them too. Like, "I am Preact and I would like to have a simple installer for me too" and so on.

We can suggest to create their own, but then they might turn around and say, "hey you got react and we are as popular and top notch". That's why I thought perhaps removing this whole thing would be ideal meaning it's same level playing field for all. Or, other solution would be is if we cleanup the tasks file and have a separate task for each framework that gets added into the Gem and suggest everyone with a PR to follow that convention.

Although, it sounds like that later one will add some extra work for the folks who are maintaining the Gem because things change so fast in JS realm. That is all my concern :)

[dhh]

@renchap @gauravtiwari Appreciate your guys' thoughts on this. I think this is probably one of those times where the natural proclivities of Ruby vs JavaScript ecosystems shine through. In JS, it seems like no module is too small to be turned into its own dependency. In Ruby, we're a bit more hesitant to create a lot of tiny dependencies. There's overhead in keeping things in sync, releasing, and other housework that has to be outweighed by the advantages of extraction. In this case, I don't see strong advantages.

There's been a flurry of activity on this repo lately and it hasn't been around adding 101 different HELLOs for obscure frameworks. So I think the perceived onslaught probably isn't so likely to happen. But even if it does, I'm happy to help sort out what makes sense to include and what doesn't. In my opinion, we just need to deal with the majors, which we kinda already have.

So for now, let's leave things as they are. We can always revisit if we get flooded with submissions. But even then, we'd probably just go with a webpacker-* style for those additional submissions. Not for things like React.

[gauravtiwari]

@dhh Yes, I kinda of realised this too so, perhaps something to revisit when the situation actually arises in the future. Sounds good 👍

Thank you :)

[thewoolleyman]

Yes, strongly in favor of this. I plan on using Elm, so anything react/angular/etc would be useless to me, and just bloat.

I would prefer that this gem be focused on only the parts that are generally useful for any framework, present or future, that can be compiled/transpiled to JS via webpack.

[dleavitt]

So to proceeded, we'd want someone from rails core to create webpacker-react, webpacker-angular and webpacker-vue repos? Our just let people host them outside of Rails for now?

[gauravtiwari]

@dhh Absolutely, I see your point, however this isn't the same setup as Rails. Rails, as a web-application framework requires a database by default to work with. It's critical there, however it's not the same relationship here. The analogy would be correct if we go to same length to integrate react or angular in the same way it's with PG or MySQL in Rails.

What we are doing currently is running yarn add react react-dom and then generating an example component file. This setup is available all over the internet and anyone who just follows a readme can add it without a problem. That's why I just pointed to perhaps not have it in the first place because it's adds out of context bloat in this gem, which isn't the problem we are truly solving. We can add all these parts in the readme though, which I think is best place for this to go.

In regards to an example app, we can create a Vanilla es6 app, that demos most of the fancy stuff used in modern javascript. This will take away a lot of problem from us that we might have to handle if we have this - out of context questions and PR's (add my new fancy framework).

[gauravtiwari]

@renchap That is all I am suggesting :)

[rafaelfranca]

Just to understand what is the problem with having a small, curated set of integrations in this gem?