3 ms·
I wouldn’t use language quite as strong as yours, but I have always preferred working without it outside of a quick prototype. It’s just so many dependencies th
by 52-6F-62 7y ago
I wouldn’t use language quite as strong as yours, but I have always preferred working without it outside of a quick prototype. It’s just so many dependencies that aren’t really needed... I can’t justify it.
I’ve seen some messy, messy work as a result of it. It’s not even CRA’s direct fault, but it has a lot of people convinced that everything is there and you can just run with it from there.
That is extended by some of the advice that if you need a small utility function you should just install a package instead of writing the 3-liner yourself. I find that kind of advice seems to be aligned with CRA in the community.
And on a personal level I prefer having more control over my build methods. Not an overly huge fan of react-scripts on that note, either.
All this said, I haven’t touched it for some time.
- brlewis 7y agoI only used it recently, 3.0.1, but it has seemed clean to me. But I'm the opposite re. build methods. I'd rather not think about build methods and just stay focused on the app.
- lioeters 7y agoI'm in the same camp, I feel neutral about CRA - it's great for getting set up quick, but comes with a whole jungle of complexity, even if it's under a simpler abstraction most of the time. I just bit the bullet a few years ago and invested time into learning all the moving parts of a full-stack React app, and created generic build scripts with common libraries - it has everything I need and nothing more. I've continued using it to this day, keeping it up to date has been painless mostly, and have built a number of business applications with it. A big advantage of CRA I see is that it provides a standard, well-developed and documented. It's suited for onboarding junior team members, as well as allowing people to jump into new codebases.