Install Node, run `npx create-react-app my-site` and you're all configured.
Install Node, run `npx create-react-app my-site` and you're all configured.
For example, on the reactjs.docs, https://reactjs.org/docs/create-a-new-react-app.html, create-react-app is simply one of four toolkits recommended, along with countless others in open source land.
There are folks who like to live on the bleeding edge, and for those using something else (or ejecting) might even make sense... maybe. But for any production app you should just use CRA, otherwise you will find yourself explaining to your new hire all the obscure choices you made a year or two ago. Believe me, I've been on the receiving end of these explanations and it sucks.
CRA has its place, certainly. But it is a black box, and somebody in your org should know the tools well enough to make good decisions to build up a product from scratch without CRA... and then you may still choose to use CRA, but it is an educated choice, not a default answer because you do not know any other options.
What is that one use case? What are the others that don't fit?
Yes, 100%, if you have more exotic requirements from a bundler or build toolchain then you'll need to look elsewhere and probably have to start learning tools like Webpack in more detail. I try and avoid those requirements.
Now I have a package/webpack/tsconfig files that I just re-use (and update as needed) between projects. I've never encountered a problem I couldn't solve. Sure now I need to manage the configuration of each project, but, I kid you not, my webpack.config.js file is 100 LoC total. This includes everything most projects probably need: Dev server setup and proxying, JS minification, JS bundling/code splitting, and SCSS/CSS transformation and purging.
I'm sure other projects have other needs, but it's really not that hard to understand these technologies.
And don't give me this "But all of that code is there to help you!" lecture. I've been deploying reasonably complex React apps since its inception, and have yet to encounter the kinds of edge cases to which the above sentiment is likely referring. Hey, maybe I'm just lucky...
I like CRA, it's my default go-to because i want to avoid maintaining a webpack configuration. If you have a solution that works for you, that's good too!
The build process of a modern React application has a certain amount of necessary complexity. Hiding it behind a "low-effort" build tool like CRA doesn't change the above and, frankly, is really a disservice to anyone who wants to understand the tools they are working with.
Go ahead, eject a CRA sometime. See how "low-effort" it really is...
I decided to try my hand at using CRA for the first (and last) time to build a small app at work because it had recently hit the scene, and appeared to be fast-becoming the idiomatic way of engaging with the library and ecosystem. I don't even remember why at this point anymore, but I had some issue that required me (as in the docs at the time said so) to eject the app. My jaw literally dropped after I saw what the project had become. It was... thousands of LoC. And spread across so many files!
Clearly we have different definitions of "too hard", but, to me, the task of understanding all of that was "too hard". I am simply not wired in a way such that I can use a tool without understanding how it works (obviously within reason). I have to imagine that when you say you "didn't want to maintain a webpack configuration" that you mustn't really understand what that entails, and are using the output from an ejected CRA as a proxy for what that configuration must look like. I assure you, it's rather simple. I've spent 20 minutes in the last 3 years doing so.
[0] I would estimate the kinds of apps that I build are far more complex than the vast majority of use-cases (think fantasy sports draft/league management software).