7 ms·

Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when

Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when working on it? The CLI probably enables a few dozen features, of which you might use a handful of. So there's all these files and configuration code in your project that is never touched/used. I imagine it's a lot of white noise. Whenever I start new projects, I cleanroom start with an empty git repo. Every line, in every file, has a purpose. (With time, there is some slippage. A feature could get removed, and some code doesn't get eliminated that should, for example). But all in all, the vast majority of the code there serves a purpose. Little to no mental energy is spent worrying about side effects or filtering through code that's not only not relevant to my current work, but has no present value in the project at all. I take a functional style, with the above, to allow myself to really be able to focus on my work. I sometimes feel alone in this approach, but it works for me and I see it's benefits. I place a big premium on clarity.

SenHeng 7y ago
I typically start such a new project by cloning from a boiler plate repo that I created myself. I find those easier to use than CRA.
- rajatsharma91 7y ago
  That's a good strategy, I occasionally use that too, but a better strategy is to keep isolating often repeated functionality in your project and turn them into library packages, so you can simply add them as a dependency from now on. This way, you boilerplate becomes smaller over time or you can even start from scratch easily.
  - jholman 7y ago
    The repeated functionality that belongs in a boilerplate is literally all that CRA does. That's what makes a boilerplate a boilerplate.
- JMTQp8lwXL 7y ago
  I have my own babel+webpack+etc repo I clone for mini-things I want to dig into (e.g., how does "tool x" work?) and I can freely explore learning that tool, without clouding my production important code base. I then transport those learnings back, and the implementation is more refined, since it's clearly written by somehow who knows how to effectively use Tool X, without haphazardly throwing it around.
- Keats 7y ago
  I do the same. I find it much easier to understand and I've always needed to modify the config anyway. I wrote about my own boilerplate in https://www.vincentprouillet.com/blog/react-typescript-webpack-1/ https://www.vincentprouillet.com/blog/react-typescript-webpa... and the Webpack config is like 75 lines. It could work with Vue or anything else just as well. My guess is people still think Webpack is hard to configure despite that being quite simple now.
- 52-6F-62 7y ago
  I do the exact same. I find this is especially important where license and dependency management is a concern.
cstuder 7y ago
CRA sets up a completely working development environment, I can start coding immediatly. The code I have to remove from CRA is minimal (Clean out App.js, delete the CSS file). It saves a _lot_ of mental energy for me. Otherwise I would first spend half an hour setting up Webpack, Babel, Prettier, eslint etc. before even writing a single line of code.
acemarke 7y ago
No, because CRA explicitly encapsulates and hides all that functionality inside the `react-scripts` package. You only add a single dependency to your own app's `package.json`. All the config files are in `node_modules/react-scripts/config` if you really want to look at them, but otherwise they're effectively hidden. In return, you get: - A Webpack+Babel build config that has excellent default behavior out of the box for browser support and code splitting, and supports working with many common types of assets including images, CSS, and SASS - The Jest unit test runner configured to automatically pick up any test files - A linting ruleset that only warns for potential errors - An error overlay that pops up whenever there's a UI crash, minimizes irrelevant parts of the stack trace, and lets you jump to the relevant lines in your editor - The ability to easily update to improvements in the build system (such as this 3.3.0 release) simply by updating the `react-scripts` dependency. And, CRA has had a _ton_ of work put into it to smooth over various pain points and incompatibilities between browsers, Node, and the various tools that it's built on. While CRA doesn't have a built-in way to override its config files, there are several widely used "CRA override" tools like `craco` [0] that allow you to opt-in to modifying parts of the config to suit your needs. I personally no longer have a need to "eject" a CRA project, as the override tools are more than sufficient to let me make whatever config edits I need (such as [1]). CRA has eliminated the question of "How do I set up a working build setup for a React project?", and made it way easier for folks to write tutorials that focus on the code, not the build setup. [0] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco [1] https://github.com/markerikson/cra-spectacle-mdx-boilerplate/blob/master/config-overrides.js https://github.com/markerikson/cra-spectacle-mdx-boilerplate...
- JMTQp8lwXL 7y ago
  Correct me if I'm wrong, but if you eject, all of those files and NPM dependencies are just dumped into your main package, even if you didn't need that configuration? E.g., let's say CRA supports SCSS files. You eject and now you have a webpack config that can handle SCSS files, but your project doesn't use them. Now you have white noise. A really small, and potentially trivial example, but that sort of buildup is death by a thousand cuts to a project. "What does this line do?" "Do we need it?" future engineers will ponder. Also, it'd add more substance to the discussion, but I really am curious how many people eject. Is it, the minute it (CRA) can't do what you need, you have to eject? Or it becomes exceptionally difficult to interface with a tool that just abstracts away more tools? It's possible those abstractions might not give you the full level of customization would could potentially need, if project requirements shift. CRACO seems like an admission that CRA, on its own, could be somewhat half baked. The ability to want to override some things without fully ejecting seems like an obviously wanted feature of a toolkit.
woutr_be 7y ago
I recently did a project that used the create-react-app CLI, and felt a bit anxious. I know the setup that create-react-app creates, but I still prefer to write this all myself. Most, if not every project I do, I start from scratch, and build the pipeline when I have a need for it. It also forces me to understand the way my app will be build. I've met a lot of developers who only use these pre-build setups, or only use bootstrapped templates that they don't even know what they do, and personally, that scares me.
latchkey 7y ago
Personally, I love working on features and building apps more than I like dealing with the esoteric and always changing ins and outs of java/typescript build systems. CRA solves that problem for me, without creating a lot of cruft in my folder. That certainly does not excuse me from learning how to use craco to define babel plugins to make sure my material-ui imports are optimized [1], but it does end up saving me a lot of time that I'd rather spend elsewhere. I've also found that CRA produces smaller apps than even Parcel 1... which apparently is fixed in Parcel 2, but I have yet to try it as it is still in development 3 months after I finished my last project. ;-) [1] https://material-ui.com/guides/minimizing-bundle-size/#option-2 https://material-ui.com/guides/minimizing-bundle-size/#optio...
rajatsharma91 7y ago
You are absolutely right! The quantity of white noise is so much that at some point of time, you'll end up thinking that it would have been much easier had I started this project from scratch instead of inheriting this monstrous code! You use CLI generators for hand-holding, so that you don't have to write lots of code but this works in only the basic hello world kind of projects. As your project gets larger, this same hand-holding gets in your way as you have to understand, twist and tweak someone else's code unnecessarily.
- jakelazaroff 7y ago
  What white noise? None of the configuration files are exposed unless you eject. I also disagree with your assertion that this only works for basic “hello world” type projects. I’ve yet to work on a project that’s been hampered by CRA’s limitations; I’d reckon it’s sufficient for at least 90% of React apps.
- brlewis 7y ago
  I think you have in mind something that's very different from create-react-app.
t0astbread 7y ago
I'm also working with a custom build flow now but I always found CRA to be way easier. It just works vs. with a custom webpack/babel/etc setup there's so many moving parts that I had to manage that it never worked as well as a CRA project. Afaik CRA also hides most (all?) config files from you until you eject. For the custom setup I'm using now I tried Parcel and I must say it's pretty good. It hides a lot of the complexities of webpack+babel but it also has its limitations (in, like, a different way though that makes it a better fit for my project).
dmitriid 7y ago
CRA (and other CLI tools for other projects) provide out-of-the-box functionality that you already want, most likely. Sadly, you have to fight the creators of the underlying tools tooth and nail to make that functionality the default behavior. Run CRA eject and look at the horror that is the resulting configs.
ergothus 7y ago
I normally hate boilerplate apps. CRA is an exception. It doesnt pre create any content of significance. ( basically a hello world page, although it has a demo image file to rip out) It does create a build process, but not content. This frees me to focus on my code. Were I to struggle with getting the build to work when that isnt my goal, I'd likely half ass it, make basic errors, and struggle to reinvent the wheel. (Actually, I know this because I do periodically do this just to make sure I understand what CRA does for me. Each time I find months of changes and tweaks I have to learn that I definitely suck at keeping up on even when I have a project that doesnt use a boilerplate) CRA isnt like other boilerplate apps - either I dont get your point or you choose a poor example to hang your point off of.
- Vinnl 7y ago
  I guess a large part of that is that you literally don't have to worry about the stuff that CRA does for you behind the scenes. With most boilerplates, after you clone it you have to check for updates, and whatever you do with it afterwards is your own responsibility - including e.g. updating configuration when the tools you use change, completely negating the purported advantage of that boilerplate. With CRA, you simply update react-scripts and you should be mostly there. But the main advantage of CRA is the fact that it satisfies the needs of the vast majority of the ecosystem, allowing other tools to assume that config for their default setup. For example, enabling Storybook for a CRA-created app hardly any effort.
nindalf 7y ago
I think CRA's core audience is people like me - JS noobs. I have no idea about all the things I need to do to start a JS project or how to get it deployed. CRA tells me - "just run this line and you're good to go". The goal is lowering the barrier to entry by giving sane defaults. Will I understand everything that's happening? No, but that's a non-goal when I'm starting out. The hope is that I get started, google the stuff I don't understand and gradually understand all the components and why they're there. When I become a JS pro, it's possible the sane defaults won't work for me and I'll choose something else, with an approach similar to yours.
- acemarke 7y ago
  I'm a JS and React _expert_, and I still use CRA all the time whenever I want to spin up a new project because I don't want to take the time to mess with all the build setup. I just want something that works right.
  - jakelazaroff 7y ago
    Same here. Debugging build issues might be one of the most frustrating and boring parts of development, especially because 99% of apps need basically the same setup. CRA gets a new app with good defaults up and running in like thirty seconds. And there’s no magic — if you outgrow it you can always eject.
  - nindalf 7y ago
    I said "it's possible I might choose your approach", meaning the option is open to me - CRA defaults or completely custom. You have the option to go either way. Whereas a noob should just use CRA.
    - acemarke 7y ago
      Right, I was just trying to clarify that even as a non-newbie, CRA has benefits and is my tool of choice.
xixixao 7y ago
Btw CRA is essentially what traditional IDEs have had for decades baked in - it’s just that the JS world doesn’t (yet) revolve around monolithic IDEs.
servercobra 7y ago
One of the biggest benefits of these CLIs is they give everyone a common starting point. If everyone is putting together their own webpack config, etc, the chances of finding someone who can quickly answer "why isn't X working" go down drastically. That's awesome for beginners and advanced users alike.
- acemarke 7y ago
  Exactly. It used to be that every single React tutorial started with "First, we're going to install Webpack and Babel", and half the tutorial would be filled with configuring those before it even got to the React code. As a specific example, 3 years ago a React tutorial for building a Yelp clone made it onto the front page of HN [0]. The comments bashed it for spending a ton of time on build setup (and somewhat justifiably so). Now, React tutorials just start with "run `create-react-app my-app`", and go from there. [0] https://news.ycombinator.com/item?id=11778663 https://news.ycombinator.com/item?id=11778663
z3t4 7y ago
create-react-app installs almost one million packages. So I understand why one don't want to do that manually. But that is crazy!
- acemarke 7y ago
  Nitpicking: last time I checked, it was around 1500. Which is still way too many, and I'd love it if the JS community would spend some time working on collapsing the dependency trees for widely used tools like Webpack.
  - marcthe12 7y ago
    It's already happening but slowly. Mainly because of some high profile incidents regarding huge dep trees and dropping support of old browsers and runtimes which means usage of native APIs. Webpack 5 has half of webpack4 deps for example.
    - acemarke 7y ago
      Really? I hadn't looked at Webpack 5 yet. If that's the case, that's great!
  - z3t4 7y ago
    When I ran create-react-app npm said it audited 960000 packages. I wonder where it got that number from then?
    - acemarke 7y ago
      I honestly have no idea where NPM pulls its audit numbers from. If I open up npmjs.com right now, it says there's 1,153,926 packages in total on NPM. While CRA does have a bunch of transitive dependencies, I can guarantee that CRA does _not_ depend on 83% of the entire NPM registry :)
GeneralMaximus 7y ago
I say this as someone who has been paid ridiculous amounts of money just to help configure and improve build systems: please just use CRA for all your React projects. Or, if you need server-side rendering, use Next.js. There are, like, five people in the world who have any business manually configuring Webpack+Babel+SASS+TypeScript+$WHATEVER, and all of those people are already working on CRA. Modern frontend build tooling is complex, and getting it right in a way that it's (a) correct, (b) maintainable, (c) extensible, and (d) upgradeable is ridiculously hard. You'll make mistakes that will cause your bundles to balloon in size, or produce assets you never asked for, or fail to produce assets you really needed. You'll be asked to add features to the system that will require full refactors of everything because you didn't think of extensibility upfront. You'll accidentally use libraries that end up being abandoned, or those that break compatibility. You'll want to upgrade to new versions of a single tool, but you'll be stuck in dependency hell where upgrading TypeScript will require a new version of Babel, which will require a new version of Webpack, which will require new versions of seventeen random libraries, and now you're spending your entire week fixing the build instead of writing features. I know CRA has more features than a lot of people need. But deal with the white noise (and a few extra megabytes of node_modules) and just use it without ejecting. A huge team of smart people is already doing all the dirty work of making sure builds work as expected so you can concentrate on features. Please just use their work.
- awongh 7y ago
  I've been finding that I go outside the base config quite quickly. I wanted to compile a second app with different babel settings and have that in my webpack config. I gave up on it after a few hours of trying to figure out what I would need. Is this really a super rare case that only experts should attempt? When I ejected CRA it gave me a 600 line config file. I think I also find the general attitude of the community ("it's all modular!") to be disingenuous. Just bundle all this stuff into a monoremp massive npm package and be done with it, ala rails.
  - chrisweekly 7y ago
    I think CRA does an amazingly good job for the standard non-ejected scenario. Ejecting and hacking on the output is educational, but rarely a good idea. Which is fine. My chief complaint is the lack of robust, non-ejection extensibility. Projects like CRACO, and babel macros, IMHO should be standard and officially supported.
stupidcar 7y ago
No, because what these CLIs actually provide is a preconfigured build system, not the straw-man overstuffed boilerplate you are suggesting they do. Do I miss spending hours configuring Webpack builds, CSS and HTML processors, JS compilers, linters, unit and e2e testing frameworks, dev servers and npm dependencies before I can even start coding on the problem I really want to solve? No, I do not.
pavlov 7y ago
I think of CRA as a cost of doing business in today's web apps, just like the cost of doing Android dev is to download Android Studio and let it install bazillion GBs of stuff; the cost of doing iOS dev is to buy a Mac, install Xcode and pay Apple an annual $99; etc. Except the Apple tax, you can always work around those costs: for example, build Android apps with no IDE and no simulator and writing your own makefiles from scratch. But that doesn't really make any sense if your development work is any sort of business. If your hobby is toolchain configuration, then go for it. CRA feels the same to me.
- 52-6F-62 7y ago
  I disagree. Facebook released a highly competent Web UI library, and it was a game changer for how I thought about UI on the web at all. Do I want to give my entire build process for the web to them? No. Android Studio was released by the group who released the platform. XCode was released by the group who released the platform. Facebook didn’t build the web. I personally prefer having much more control over what code goes into my app.
jholman 7y ago
Every month some new batch of students use CRA for their final project. Every other month month I deal with some idiotic mess CRA has made that a 3-line patch to a config file would fix, but I can't fix that without ejecting, which all the advice tells them not to do. Often it's proxy problems, sometimes it's something else, I can't really keep track. I hate CRA, and I wish it would go die in a hole. Though... in this comment thread I learned of the existence of something called "craco", so maybe that'll solve my problems the next time some damn students use stupid CRA when they could just copy and paste the frickin' working webpack config we gave them in the previous assignment.
- petetnt 7y ago
  Hi jholman, part-time maintainer of CRA here. Sorry that Create React App has caused you and your students problems. Would have a specific list of issues (or specific ones like proxy issues) that you needed to eject for to fix that we could look at and improve in the future?
  - mbeaudru 7y ago
    This one for instance: https://github.com/facebook/create-react-app/issues/6135 https://github.com/facebook/create-react-app/issues/6135 If you need to use CRA behind a different publicPath in dev (behind a gateway) you can't and need to eject.
- 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.
dragonwriter 7y ago
> Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when working on it? Depends on the CLI. The AWS SAM CLI or create-react-app or poetry for python, no. But certainly I've run into some where that's the case. > The CLI probably enables a few dozen features, of which you might use a handful of. Depends on the CLI. Certainly many do not have this problem. > Little to no mental energy is spent worrying about side effects or filtering through code that's not only not relevant to my current work, but has no present value in the project at all. Yeah, and that's nice, but IME this isn't a problem with code from a good-fit-for-purpose CLI; this isn't a place where I'm burning energy with, e.g., SAM or poetry, or even CRA (though in the last case I can imagine circumstances where it would be an issue, but it hasn't been for me in practice.)
brlewis 7y ago
Actually cra hides the boilerplate configuration in react-scripts. If you want to touch the configuration that you never need to touch, there's eject. It's my intention never to use eject. The only useless thing I recall removing was some service worker code in the default template. If that bothers you it looks like they're making it easy for you to make your own template that's even leaner.

SenHeng 7y ago

I typically start such a new project by cloning from a boiler plate repo that I created myself. I find those easier to use than CRA.

rajatsharma91 7y ago
That's a good strategy, I occasionally use that too, but a better strategy is to keep isolating often repeated functionality in your project and turn them into library packages, so you can simply add them as a dependency from now on. This way, you boilerplate becomes smaller over time or you can even start from scratch easily.
- jholman 7y ago
  The repeated functionality that belongs in a boilerplate is literally all that CRA does. That's what makes a boilerplate a boilerplate.
JMTQp8lwXL 7y ago
I have my own babel+webpack+etc repo I clone for mini-things I want to dig into (e.g., how does "tool x" work?) and I can freely explore learning that tool, without clouding my production important code base. I then transport those learnings back, and the implementation is more refined, since it's clearly written by somehow who knows how to effectively use Tool X, without haphazardly throwing it around.
Keats 7y ago
I do the same. I find it much easier to understand and I've always needed to modify the config anyway. I wrote about my own boilerplate in https://www.vincentprouillet.com/blog/react-typescript-webpack-1/ https://www.vincentprouillet.com/blog/react-typescript-webpa... and the Webpack config is like 75 lines. It could work with Vue or anything else just as well. My guess is people still think Webpack is hard to configure despite that being quite simple now.
52-6F-62 7y ago
I do the exact same. I find this is especially important where license and dependency management is a concern.

cstuder 7y ago

CRA sets up a completely working development environment, I can start coding immediatly. The code I have to remove from CRA is minimal (Clean out App.js, delete the CSS file). It saves a _lot_ of mental energy for me. Otherwise I would first spend half an hour setting up Webpack, Babel, Prettier, eslint etc. before even writing a single line of code.

acemarke 7y ago

No, because CRA explicitly encapsulates and hides all that functionality inside the `react-scripts` package. You only add a single dependency to your own app's `package.json`. All the config files are in `node_modules/react-scripts/config` if you really want to look at them, but otherwise they're effectively hidden. In return, you get: - A Webpack+Babel build config that has excellent default behavior out of the box for browser support and code splitting, and supports working with many common types of assets including images, CSS, and SASS - The Jest unit test runner configured to automatically pick up any test files - A linting ruleset that only warns for potential errors - An error overlay that pops up whenever there's a UI crash, minimizes irrelevant parts of the stack trace, and lets you jump to the relevant lines in your editor - The ability to easily update to improvements in the build system (such as this 3.3.0 release) simply by updating the `react-scripts` dependency. And, CRA has had a _ton_ of work put into it to smooth over various pain points and incompatibilities between browsers, Node, and the various tools that it's built on. While CRA doesn't have a built-in way to override its config files, there are several widely used "CRA override" tools like `craco` [0] that allow you to opt-in to modifying parts of the config to suit your needs. I personally no longer have a need to "eject" a CRA project, as the override tools are more than sufficient to let me make whatever config edits I need (such as [1]). CRA has eliminated the question of "How do I set up a working build setup for a React project?", and made it way easier for folks to write tutorials that focus on the code, not the build setup. [0] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco [1] https://github.com/markerikson/cra-spectacle-mdx-boilerplate/blob/master/config-overrides.js https://github.com/markerikson/cra-spectacle-mdx-boilerplate...

JMTQp8lwXL 7y ago
Correct me if I'm wrong, but if you eject, all of those files and NPM dependencies are just dumped into your main package, even if you didn't need that configuration? E.g., let's say CRA supports SCSS files. You eject and now you have a webpack config that can handle SCSS files, but your project doesn't use them. Now you have white noise. A really small, and potentially trivial example, but that sort of buildup is death by a thousand cuts to a project. "What does this line do?" "Do we need it?" future engineers will ponder. Also, it'd add more substance to the discussion, but I really am curious how many people eject. Is it, the minute it (CRA) can't do what you need, you have to eject? Or it becomes exceptionally difficult to interface with a tool that just abstracts away more tools? It's possible those abstractions might not give you the full level of customization would could potentially need, if project requirements shift. CRACO seems like an admission that CRA, on its own, could be somewhat half baked. The ability to want to override some things without fully ejecting seems like an obviously wanted feature of a toolkit.

woutr_be 7y ago

I recently did a project that used the create-react-app CLI, and felt a bit anxious. I know the setup that create-react-app creates, but I still prefer to write this all myself. Most, if not every project I do, I start from scratch, and build the pipeline when I have a need for it. It also forces me to understand the way my app will be build. I've met a lot of developers who only use these pre-build setups, or only use bootstrapped templates that they don't even know what they do, and personally, that scares me.

latchkey 7y ago

Personally, I love working on features and building apps more than I like dealing with the esoteric and always changing ins and outs of java/typescript build systems. CRA solves that problem for me, without creating a lot of cruft in my folder. That certainly does not excuse me from learning how to use craco to define babel plugins to make sure my material-ui imports are optimized [1], but it does end up saving me a lot of time that I'd rather spend elsewhere. I've also found that CRA produces smaller apps than even Parcel 1... which apparently is fixed in Parcel 2, but I have yet to try it as it is still in development 3 months after I finished my last project. ;-) [1] https://material-ui.com/guides/minimizing-bundle-size/#option-2 https://material-ui.com/guides/minimizing-bundle-size/#optio...

rajatsharma91 7y ago

You are absolutely right! The quantity of white noise is so much that at some point of time, you'll end up thinking that it would have been much easier had I started this project from scratch instead of inheriting this monstrous code! You use CLI generators for hand-holding, so that you don't have to write lots of code but this works in only the basic hello world kind of projects. As your project gets larger, this same hand-holding gets in your way as you have to understand, twist and tweak someone else's code unnecessarily.

jakelazaroff 7y ago
What white noise? None of the configuration files are exposed unless you eject. I also disagree with your assertion that this only works for basic “hello world” type projects. I’ve yet to work on a project that’s been hampered by CRA’s limitations; I’d reckon it’s sufficient for at least 90% of React apps.
brlewis 7y ago
I think you have in mind something that's very different from create-react-app.

t0astbread 7y ago

I'm also working with a custom build flow now but I always found CRA to be way easier. It just works vs. with a custom webpack/babel/etc setup there's so many moving parts that I had to manage that it never worked as well as a CRA project. Afaik CRA also hides most (all?) config files from you until you eject. For the custom setup I'm using now I tried Parcel and I must say it's pretty good. It hides a lot of the complexities of webpack+babel but it also has its limitations (in, like, a different way though that makes it a better fit for my project).

dmitriid 7y ago

CRA (and other CLI tools for other projects) provide out-of-the-box functionality that you already want, most likely. Sadly, you have to fight the creators of the underlying tools tooth and nail to make that functionality the default behavior. Run CRA eject and look at the horror that is the resulting configs.

ergothus 7y ago

I normally hate boilerplate apps. CRA is an exception. It doesnt pre create any content of significance. ( basically a hello world page, although it has a demo image file to rip out) It does create a build process, but not content. This frees me to focus on my code. Were I to struggle with getting the build to work when that isnt my goal, I'd likely half ass it, make basic errors, and struggle to reinvent the wheel. (Actually, I know this because I do periodically do this just to make sure I understand what CRA does for me. Each time I find months of changes and tweaks I have to learn that I definitely suck at keeping up on even when I have a project that doesnt use a boilerplate) CRA isnt like other boilerplate apps - either I dont get your point or you choose a poor example to hang your point off of.

Vinnl 7y ago
I guess a large part of that is that you literally don't have to worry about the stuff that CRA does for you behind the scenes. With most boilerplates, after you clone it you have to check for updates, and whatever you do with it afterwards is your own responsibility - including e.g. updating configuration when the tools you use change, completely negating the purported advantage of that boilerplate. With CRA, you simply update react-scripts and you should be mostly there. But the main advantage of CRA is the fact that it satisfies the needs of the vast majority of the ecosystem, allowing other tools to assume that config for their default setup. For example, enabling Storybook for a CRA-created app hardly any effort.

nindalf 7y ago

I think CRA's core audience is people like me - JS noobs. I have no idea about all the things I need to do to start a JS project or how to get it deployed. CRA tells me - "just run this line and you're good to go". The goal is lowering the barrier to entry by giving sane defaults. Will I understand everything that's happening? No, but that's a non-goal when I'm starting out. The hope is that I get started, google the stuff I don't understand and gradually understand all the components and why they're there. When I become a JS pro, it's possible the sane defaults won't work for me and I'll choose something else, with an approach similar to yours.

acemarke 7y ago
I'm a JS and React _expert_, and I still use CRA all the time whenever I want to spin up a new project because I don't want to take the time to mess with all the build setup. I just want something that works right.
- jakelazaroff 7y ago
  Same here. Debugging build issues might be one of the most frustrating and boring parts of development, especially because 99% of apps need basically the same setup. CRA gets a new app with good defaults up and running in like thirty seconds. And there’s no magic — if you outgrow it you can always eject.
- nindalf 7y ago
  I said "it's possible I might choose your approach", meaning the option is open to me - CRA defaults or completely custom. You have the option to go either way. Whereas a noob should just use CRA.
  - acemarke 7y ago
    Right, I was just trying to clarify that even as a non-newbie, CRA has benefits and is my tool of choice.

xixixao 7y ago

Btw CRA is essentially what traditional IDEs have had for decades baked in - it’s just that the JS world doesn’t (yet) revolve around monolithic IDEs.

servercobra 7y ago

One of the biggest benefits of these CLIs is they give everyone a common starting point. If everyone is putting together their own webpack config, etc, the chances of finding someone who can quickly answer "why isn't X working" go down drastically. That's awesome for beginners and advanced users alike.

acemarke 7y ago
Exactly. It used to be that every single React tutorial started with "First, we're going to install Webpack and Babel", and half the tutorial would be filled with configuring those before it even got to the React code. As a specific example, 3 years ago a React tutorial for building a Yelp clone made it onto the front page of HN [0]. The comments bashed it for spending a ton of time on build setup (and somewhat justifiably so). Now, React tutorials just start with "run `create-react-app my-app`", and go from there. [0] https://news.ycombinator.com/item?id=11778663 https://news.ycombinator.com/item?id=11778663

z3t4 7y ago

create-react-app installs almost one million packages. So I understand why one don't want to do that manually. But that is crazy!

acemarke 7y ago
Nitpicking: last time I checked, it was around 1500. Which is still way too many, and I'd love it if the JS community would spend some time working on collapsing the dependency trees for widely used tools like Webpack.
- marcthe12 7y ago
  It's already happening but slowly. Mainly because of some high profile incidents regarding huge dep trees and dropping support of old browsers and runtimes which means usage of native APIs. Webpack 5 has half of webpack4 deps for example.
  - acemarke 7y ago
    Really? I hadn't looked at Webpack 5 yet. If that's the case, that's great!
- z3t4 7y ago
  When I ran create-react-app npm said it audited 960000 packages. I wonder where it got that number from then?
  - acemarke 7y ago
    I honestly have no idea where NPM pulls its audit numbers from. If I open up npmjs.com right now, it says there's 1,153,926 packages in total on NPM. While CRA does have a bunch of transitive dependencies, I can guarantee that CRA does _not_ depend on 83% of the entire NPM registry :)

GeneralMaximus 7y ago

I say this as someone who has been paid ridiculous amounts of money just to help configure and improve build systems: please just use CRA for all your React projects. Or, if you need server-side rendering, use Next.js. There are, like, five people in the world who have any business manually configuring Webpack+Babel+SASS+TypeScript+$WHATEVER, and all of those people are already working on CRA. Modern frontend build tooling is complex, and getting it right in a way that it's (a) correct, (b) maintainable, (c) extensible, and (d) upgradeable is ridiculously hard. You'll make mistakes that will cause your bundles to balloon in size, or produce assets you never asked for, or fail to produce assets you really needed. You'll be asked to add features to the system that will require full refactors of everything because you didn't think of extensibility upfront. You'll accidentally use libraries that end up being abandoned, or those that break compatibility. You'll want to upgrade to new versions of a single tool, but you'll be stuck in dependency hell where upgrading TypeScript will require a new version of Babel, which will require a new version of Webpack, which will require new versions of seventeen random libraries, and now you're spending your entire week fixing the build instead of writing features. I know CRA has more features than a lot of people need. But deal with the white noise (and a few extra megabytes of node_modules) and just use it without ejecting. A huge team of smart people is already doing all the dirty work of making sure builds work as expected so you can concentrate on features. Please just use their work.

awongh 7y ago
I've been finding that I go outside the base config quite quickly. I wanted to compile a second app with different babel settings and have that in my webpack config. I gave up on it after a few hours of trying to figure out what I would need. Is this really a super rare case that only experts should attempt? When I ejected CRA it gave me a 600 line config file. I think I also find the general attitude of the community ("it's all modular!") to be disingenuous. Just bundle all this stuff into a monoremp massive npm package and be done with it, ala rails.
- chrisweekly 7y ago
  I think CRA does an amazingly good job for the standard non-ejected scenario. Ejecting and hacking on the output is educational, but rarely a good idea. Which is fine. My chief complaint is the lack of robust, non-ejection extensibility. Projects like CRACO, and babel macros, IMHO should be standard and officially supported.

stupidcar 7y ago

No, because what these CLIs actually provide is a preconfigured build system, not the straw-man overstuffed boilerplate you are suggesting they do. Do I miss spending hours configuring Webpack builds, CSS and HTML processors, JS compilers, linters, unit and e2e testing frameworks, dev servers and npm dependencies before I can even start coding on the problem I really want to solve? No, I do not.

pavlov 7y ago

I think of CRA as a cost of doing business in today's web apps, just like the cost of doing Android dev is to download Android Studio and let it install bazillion GBs of stuff; the cost of doing iOS dev is to buy a Mac, install Xcode and pay Apple an annual $99; etc. Except the Apple tax, you can always work around those costs: for example, build Android apps with no IDE and no simulator and writing your own makefiles from scratch. But that doesn't really make any sense if your development work is any sort of business. If your hobby is toolchain configuration, then go for it. CRA feels the same to me.

52-6F-62 7y ago
I disagree. Facebook released a highly competent Web UI library, and it was a game changer for how I thought about UI on the web at all. Do I want to give my entire build process for the web to them? No. Android Studio was released by the group who released the platform. XCode was released by the group who released the platform. Facebook didn’t build the web. I personally prefer having much more control over what code goes into my app.

jholman 7y ago

Every month some new batch of students use CRA for their final project. Every other month month I deal with some idiotic mess CRA has made that a 3-line patch to a config file would fix, but I can't fix that without ejecting, which all the advice tells them not to do. Often it's proxy problems, sometimes it's something else, I can't really keep track. I hate CRA, and I wish it would go die in a hole. Though... in this comment thread I learned of the existence of something called "craco", so maybe that'll solve my problems the next time some damn students use stupid CRA when they could just copy and paste the frickin' working webpack config we gave them in the previous assignment.

petetnt 7y ago
Hi jholman, part-time maintainer of CRA here. Sorry that Create React App has caused you and your students problems. Would have a specific list of issues (or specific ones like proxy issues) that you needed to eject for to fix that we could look at and improve in the future?
- mbeaudru 7y ago
  This one for instance: https://github.com/facebook/create-react-app/issues/6135 https://github.com/facebook/create-react-app/issues/6135 If you need to use CRA behind a different publicPath in dev (behind a gateway) you can't and need to eject.
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.

dragonwriter 7y ago

> Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when working on it? Depends on the CLI. The AWS SAM CLI or create-react-app or poetry for python, no. But certainly I've run into some where that's the case. > The CLI probably enables a few dozen features, of which you might use a handful of. Depends on the CLI. Certainly many do not have this problem. > Little to no mental energy is spent worrying about side effects or filtering through code that's not only not relevant to my current work, but has no present value in the project at all. Yeah, and that's nice, but IME this isn't a problem with code from a good-fit-for-purpose CLI; this isn't a place where I'm burning energy with, e.g., SAM or poetry, or even CRA (though in the last case I can imagine circumstances where it would be an issue, but it hasn't been for me in practice.)

brlewis 7y ago

Actually cra hides the boilerplate configuration in react-scripts. If you want to touch the configuration that you never need to touch, there's eject. It's my intention never to use eject. The only useless thing I recall removing was some service worker code in the default template. If that bothers you it looks like they're making it easy for you to make your own template that's even leaner.