Hi Dan! Thanks for your reply. I think I really poorly articulated my position earlier and wish to retract. I agree with you that I don't believe understanding Acorn is important in building a React app and that CRA is a great way to be instantly productive in React. My feelings towards not using it comes from an experience I had with a different generator (Yeoman). The first time I ever tried to scaffold an Angular 1.x app with Yeoman, I completely destroyed my productivity. For some reason, the recipe I used would not play well with both ng-router and ui-router , and I ended up spending hours debugging something only to throw it all out and start from scratch. It was a tremendously valuable experience for me: I put my trust in something I didn't fully understand and learned that I couldn't figure out how to fix it. Once I decided to restart with a blank slate and be careful about the choices that I was making in the project, I had a much easier time and things just worked. This left me with the impression that struggling through setting something up at least that first time is super valuable. Thinking about this topic a lot more, I think I can find more scenarios that make create-react-app useful to more than just prototypes.

I’m fundamentally opposed to the idea of surrendering your configuration to something that may be too broad (installing dependencies that you may not need) and not fully understanding everything that’s going on under the hood. Learning how to set up your own Webpack configuration as well as architect your own React application are things that are very useful to know. If you’re trying to churn out a quick prototype, I could understand why you would want to scaffold it. Otherwise, why would you ever push code you don’t fully understand into a production environment?

I admit, I'm a huge UX snob. I recently backed down from picking a fight over the timing of validation checks in inputs on my primary project at work. On the "UX must be perfect" side (mine), I was championing implementing dirty checking in our custom React component-ized input fields because it made for a better experience. On the opposite end of the table, my PM and scrum master brought the following truths: How much better UX was not quantified Development time spent refactoring this component was better spent tackling existing issues The current state of how component validation occurred was not in any way breaking or blocking anything else from happening With these in mind, I compromised that this was not my fight to pick. Life went on just fine.

Roughly 10% of my time is probably accurate, the rest is spent thinking, discussing, grokking, and writing those pesky things we call unit tests :)

Glad it was helpful! The site is such a goldmine, happy to hear you're getting more value out of it.

I got a lot of value out of JavascriptIsSexy's post on it a few years back: http://javascriptissexy.com/understand-javascripts-this-with-clarity-and-master-it/

Chiming in a bit late. I believe frontend devs should have basic knowledge of not just Node, but what goes on in the backend in general. Same for UI/UX design. Not saying they need to be masters of each domain and be fullstack devs at all, but there's a lot of empathy to be gained from understanding how each part of the product you're building works. In the workplace, it opens up more dialogue with the rest of your team (or other teams, depending on how your company structures its engineering efforts).