4 ms·

I disagree with CRA because it promotes developers avoiding and fearing configuration files. If you are a full time front end developer and your shop uses it yo

I disagree with CRA because it promotes developers avoiding and fearing configuration files. If you are a full time front end developer and your shop uses it you NEED to learn Webpack/Babel/NPM/etc because it is a short up-front investment, will save significant amounts of time, and will lead to a noticeably better product. We're talking about hours of study leading to a long-term hundreds of hours of time saved.

acemarke 8y ago
Devs shouldn't have to spend hours setting up build configuration just to get started learning React, or every time you have a side project you want to try out. Granted, you _never_ needed Babel and Webpack _just_ to use React, but for a long time every React tutorial started with "First, we'll learn how to set up Babel and Webpack". Now, they can just say "Run `npx create-react-app my-app`", and immediately get a solid project setup that works out of the box. Nothing prevents you from still writing entire Babel and Webpack configs by hand if you want to, but it shouldn't be a prerequisite for actually using React (or any other framework).
- ben_jones 8y ago
  Couldn't you make this same argument about math curriculum? "Why should we teach algebra when its so easy to just use basic calculus for real world problems". The problem is there is a huge gap between a development react application and a production react application that is served to users with best security/operational processes. The own creators of CRA do not recommend it be used in production and isn't that the goal for most react developers, to put apps into production?
  - acemarke 8y ago
    On the contrary, CRA's docs specifically recommend it for production use: > No Configuration Required: You don't need to configure anything. A reasonably good configuration of both development and production builds is handled for you so you can focus on writing code. Nowhere in the docs do I see phrases like "don't use this in production". As for the math analogy: I'd say the difference is that many calc concepts do require understanding of algebra to grasp and use, whereas the only thing about React that _sorta_ implies knowledge of Babel is the JSX transform, which isn't a hard requirement to use React but is certainly the common preferred approach. Again, I'm not at all saying that people _shouldn't_ learn how to set up build tool configs. I agree that's valuable knowledge to have. I'm just saying it shouldn't be a hard blocker for using React, and that React tutorials shouldn't have to spend half their time teaching unrelated build tools instead of React itself.
jpochtar 8y ago
As a new web developer: what can I do once I know how to config these things, that I don’t get as part of CRA?
- ben_jones 8y ago
  Off the top of my head, I'm sure I'm missing a few obvious ones. Notably CRA doesn't prevent you from doing any of these, but taking the time to learn the various build tools will better enable it. * spend less time debugging dependencies across version changes * reduce bundle sizes * create a better CI/CD pipeline * reduce unnecessary dependencies * fork/fix/create your own plug-ins and other tools * self-hosting npm to avoid production/dev outages * easily learn new tools because you understand the underlying systems/alternatives

acemarke 8y ago

Devs shouldn't have to spend hours setting up build configuration just to get started learning React, or every time you have a side project you want to try out. Granted, you _never_ needed Babel and Webpack _just_ to use React, but for a long time every React tutorial started with "First, we'll learn how to set up Babel and Webpack". Now, they can just say "Run `npx create-react-app my-app`", and immediately get a solid project setup that works out of the box. Nothing prevents you from still writing entire Babel and Webpack configs by hand if you want to, but it shouldn't be a prerequisite for actually using React (or any other framework).

ben_jones 8y ago
Couldn't you make this same argument about math curriculum? "Why should we teach algebra when its so easy to just use basic calculus for real world problems". The problem is there is a huge gap between a development react application and a production react application that is served to users with best security/operational processes. The own creators of CRA do not recommend it be used in production and isn't that the goal for most react developers, to put apps into production?
- acemarke 8y ago
  On the contrary, CRA's docs specifically recommend it for production use: > No Configuration Required: You don't need to configure anything. A reasonably good configuration of both development and production builds is handled for you so you can focus on writing code. Nowhere in the docs do I see phrases like "don't use this in production". As for the math analogy: I'd say the difference is that many calc concepts do require understanding of algebra to grasp and use, whereas the only thing about React that _sorta_ implies knowledge of Babel is the JSX transform, which isn't a hard requirement to use React but is certainly the common preferred approach. Again, I'm not at all saying that people _shouldn't_ learn how to set up build tool configs. I agree that's valuable knowledge to have. I'm just saying it shouldn't be a hard blocker for using React, and that React tutorials shouldn't have to spend half their time teaching unrelated build tools instead of React itself.

jpochtar 8y ago

As a new web developer: what can I do once I know how to config these things, that I don’t get as part of CRA?

ben_jones 8y ago
Off the top of my head, I'm sure I'm missing a few obvious ones. Notably CRA doesn't prevent you from doing any of these, but taking the time to learn the various build tools will better enable it. * spend less time debugging dependencies across version changes * reduce bundle sizes * create a better CI/CD pipeline * reduce unnecessary dependencies * fork/fix/create your own plug-ins and other tools * self-hosting npm to avoid production/dev outages * easily learn new tools because you understand the underlying systems/alternatives