Suggest users to explore alternatives interactively

[kachkaev]

I came across a pretty nice interactive list of react-based starter kits and I think that something like this should be provided to people who grow out of create-react-app and want to explore the alternatives.

  http://andrewhfarmer.com/starter-project/

After a newcomer has played with the components and has understood the core principles, it′s common to become curious about redux, hot reloading, universal rendering and many other things that are good to hide away in the very beginning of the journey to React. Giving people a convenient entry point into this huge and growing zoo of alternatives is pretty important in IMO.

I'm not insisting that the above link should be added to README.md because I'm not sure if all good options are listed there and if the author is willing to update the data regularly. What I'd like to point out is that the section with the alternatives in the repo seems pretty poor ATM. No matter how many projects are listed there, the suggested UX for outgrowing create-react-app is far from ideal. A link to an interactive list of all sorts of starter kits will show the React ecosystem in a much higher depth.

[gaearon]

Please see my reasoning here: https://twitter.com/dan_abramov/status/779659331834880000 and below tweets.

Basically I think boilerplates attack the problem from the wrong angle by conflating build setup and code scaffolding in a single project. These are completely separate concerns, and grouping them together doesn't make sense for setups as complicated as boilerplates try to show. So I don't think this boilerplate list helps.

When we start seeing boilerplate projects focused around either just build configuration (implemented as a dependency, like Create React App or its forks), or different boilerplate projects using such build dependency and focused on runtime scaffolding, I'll be happy to reconsider. But right now they are mixing concerns.

[mxstbr]

Code scaffolding as in "Let's generate a component" or as in "Let's setup redux, react-router and immutable for you"?

[kachkaev]

I have to admit that I don't understand the logic of showing an arbitrary short list of alternatives in README.md and not listing top-used boilerplates such as one by Max. In my view, newcomers should either be encouraged to search for advanced React use cases solely by themselves or they should be given a full list of what else is available.

The way it's done now can be interpreted as “Facebook approves these projects but does not approve these ones”. I’d think exactly this way if create-react-app was created before I first encountered this library. This would definitely bias my later choice.

[gaearon]

Code scaffolding as in "Let's generate a component" or as in "Let's setup redux, react-router and immutable for you"?

The second one. Sorry I wasn't clear. I mean that these are two very different problems:

1. Configuring Webpack/Babel/Mocha/Jest/whatnot
2. Using React Bootstrap / React Router / Redux Saga / Redux DevTools

Most, if not all, boilerplates on that list conflate these unrelated problems, and as a result intimidate both beginners and experienced engineers coming into React ecosystem. Splitting these concerns into separate projects and using CRA-like build-setup-as-dependency approach seems like a potential solution to me, whether or not you maintain that build setup.

[gaearon]

I don't mean to appear confrontational. I understand a lot of effort has been put into these projects, and they are valuable to the ecosystem.

But I also want to look forward and see people thinking "getting started with React is simple even as projects becomes more complex". I also want to see people thinking "wow, there are many examples of advanced combinations of libraries in React ecosystems, and forking these examples doesn't come with maintaining a giant Webpack config that I don't understand". I want to see people thinking "oh, so I could follow this approach and separate my build from my app so I could reuse build configuration in all projects! Starting new stuff with React doesn't sound so daunting anymore".

To achieve these vision, I intend to give more visibility to projects that align closer with it. I hope we can come to a mutual understanding and work towards the vision where bundling concerns are not forced upon users who just want to learn routing or state management or async techniques, and vice versa.

[mxstbr]

I strongly agree with you on this, and this is a path react-boilerplate chose a while ago.

The entire build configuration is hidden behind the internals folder. All a user of the boilerplate has to do is write their app in the app folder, which at a cleaned state alreadt has the wiring for react-router, code splitting, redux-saga,... done so users don't have to do it.

The only difference to your ideas are that our build files aren't hidden behind a dependency, they're hidden behind a folder. I think a big part of the user group of react-boilerplate will want to (at least slightly) edit the configuration, which is why we went the folder-way and not the dependency-way. (contrary to create-react-app, which is more aimed towards beginners)

Do you think react-boilerplate should hide its internals behind a dependency? I honestly think it'd not make it "better", holistically speaking.

[gaearon]

I agree tinkering is useful and desirable for some people. I don't propose to remove that feature but to make it opt-in, or at least easy to opt out of.

The issue with "internals" folder is that once you fork, it's just there. You'll have to either update it manually (tricky when your git history diverges because your fork is your app), or you'll leave it outdated for a few months. Then next version of Webpack/Babel comes out, or there's a critical bug in a dependency, and you have to dive into it and figure out how to maintain this folder even if you never wanted to do this in the first place.

If RB is implemented as a monorepo with two packages, users could still use npm link to change configuration. However they would also have the option of just deleting the local rb-internals package, and using the one from npm maintained by the community. They'd get bugfixes and improvements without diving into details. At any point of time they could also download the rb-internals source, npm link it (or just start referring to it from the source), and tweak it. They could also publish their fork and use it as build configuration for their or their company's projects. I think that even if you want to customize things, this is more scalable than having each project contain its snowflake configuration.

[mxstbr]

I've been thinking about this, and I think you're making some great points. I can see us moving in this direction.

Could we use a fork of react-scripts for this? And just add our custom config stuff on top?

This is a major effort, so I'm not sure if I'll be able to do it soon, but this is something I want to do.

[gaearon]

Could we use a fork of react-scripts for this?

I think this doesn’t matter too much although it would be cool if the basic command names matched. You are welcome to take as much or as little as you like from it!