Create-React-App 3.3(github.com)
github.com
Create-React-App 3.3
https://github.com/facebook/create-react-app/releases/tag/v3.3.0
92 comments
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.
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
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
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.
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.
The repeated functionality that belongs in a boilerplate is literally all that CRA does. That's what makes a boilerplate a boilerplate.
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.
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-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.
My guess is people still think Webpack is hard to configure despite that being quite simple now.
I do the exact same. I find this is especially important where license and dependency management is a concern.
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.
Otherwise I would first spend half an hour setting up Webpack, Babel, Prettier, eslint etc. before even writing a single line of code.
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
[1] https://github.com/markerikson/cra-spectacle-mdx-boilerplate...
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
[1] https://github.com/markerikson/cra-spectacle-mdx-boilerplate...
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.
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.
Yes, that's what happens if you eject. But the point is that ejecting is an absolute last-ditch option that almost no one should have to resort to.
Most folks won't need to customize the standard CRA behavior. If you do, there's the community override tools.
As a specific example, two years ago I wrote a tutorial on how to use the Cesium 3D globe library with Webpack [0]. Loading Cesium at the time required changing two Webpack config options, so my tutorial started with "create a CRA app, then eject".
I recently set up a brand new CRA project that also uses Cesium. I could have used `craco` or a similar override tool to apply those Webpack config tweaks myself, but there's actually a `craco-cesium` plugin [1] that applies those edits and handles copying Cesium's assets to the CRA build output folder. This new project didn't have to eject at all.
As another example, that same project also needed to do more customization to the dev server proxying setup than CRA normally allows. CRA lets you define a simple `"proxy"` option in `package.json`, or a `setupProxy.js` file that gets a reference to the Express app to add middleware. I actually needed to apply a proxy middleware at the _end_ of the chain. `craco` let me access the actual Webpack config setup to do that [2].
The other nice thing about these override tools is that your modifications are isolated in one place, so you know exactly what changes are being made. If I were to eject and get all those config files in my project, yeah, I wouldn't know what had been edited from the originals without digging into the Git history. This way, it's one `configOverrides.js` file at most, and I get all the benefits of the rest of CRA's config which has had thousands of man-hours put into it.
[0] https://blog.isquaredsoftware.com/2017/03/declarative-earth-...
[1] https://github.com/darwin-education/craco-cesium
[2] https://twitter.com/acemarke/status/1152371310682607618
Most folks won't need to customize the standard CRA behavior. If you do, there's the community override tools.
As a specific example, two years ago I wrote a tutorial on how to use the Cesium 3D globe library with Webpack [0]. Loading Cesium at the time required changing two Webpack config options, so my tutorial started with "create a CRA app, then eject".
I recently set up a brand new CRA project that also uses Cesium. I could have used `craco` or a similar override tool to apply those Webpack config tweaks myself, but there's actually a `craco-cesium` plugin [1] that applies those edits and handles copying Cesium's assets to the CRA build output folder. This new project didn't have to eject at all.
As another example, that same project also needed to do more customization to the dev server proxying setup than CRA normally allows. CRA lets you define a simple `"proxy"` option in `package.json`, or a `setupProxy.js` file that gets a reference to the Express app to add middleware. I actually needed to apply a proxy middleware at the _end_ of the chain. `craco` let me access the actual Webpack config setup to do that [2].
The other nice thing about these override tools is that your modifications are isolated in one place, so you know exactly what changes are being made. If I were to eject and get all those config files in my project, yeah, I wouldn't know what had been edited from the originals without digging into the Git history. This way, it's one `configOverrides.js` file at most, and I get all the benefits of the rest of CRA's config which has had thousands of man-hours put into it.
[0] https://blog.isquaredsoftware.com/2017/03/declarative-earth-...
[1] https://github.com/darwin-education/craco-cesium
[2] https://twitter.com/acemarke/status/1152371310682607618
Don’t eject. The point of CRA is to abstarct away the current way to set up the build system. Instead let the guys behind CRA tune it, handle upgrades, etc. in complex projects the time spent configuring webpack and keeping versions in sync is quite severe. CRA lets you sidestep this. Somewhat.
Thankfully CRA has improved to the point where ejecting is usually no longer necessary. A few years ago, there came point on almost every serious project where requirement x, y or z forced you to eject.
> Is it, the minute it (CRA) can't do what you need, you have to eject?
I don't think there's that many uses cases that can't be done within CRA. I think there's very limited reasons to eject.
I don't think there's that many uses cases that can't be done within CRA. I think there's very limited reasons to eject.
I ejected my app, and I regret it.
Re-loading ny app i to a new CRA harness seems possible but fiddly. The last time I tried I got bogged down in dependency hell because so much had changed (unusual things like my auth library failing when backed by a more modern React). It all remains on the long-term aims list.
Re-loading ny app i to a new CRA harness seems possible but fiddly. The last time I tried I got bogged down in dependency hell because so much had changed (unusual things like my auth library failing when backed by a more modern React). It all remains on the long-term aims list.
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.
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.
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/#optio...
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/#optio...
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.
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.
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.
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.
I think you have in mind something that's very different from create-react-app.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Right, I was just trying to clarify that even as a non-newbie, CRA has benefits and is my tool of choice.
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.
create-react-app installs almost one million packages. So I understand why one don't want to do that manually. But that is crazy!
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.
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.
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.
Really? I hadn't looked at Webpack 5 yet. If that's the case, that's great!
When I ran create-react-app npm said it audited 960000 packages. I wonder where it got that number from then?
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 :)
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.
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.
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.
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.
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.
> When I ejected CRA it gave me a 600 line config file.
This is one of my least favourite thing about CRA. The equivalent Webpack config tailored to the needs of my project is generally only 100-200 lines long. CRA makes things far more complicated than it needs to be because it has to support everyone's requirements.
This is one of my least favourite thing about CRA. The equivalent Webpack config tailored to the needs of my project is generally only 100-200 lines long. CRA makes things far more complicated than it needs to be because it has to support everyone's requirements.
Out of curiosity, what do you end up needing that's not supported by default by CRA (or Next or Gatsby)? I've started a bunch of apps with CRA, and not once have I needed anything that's not already there.
> 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.
I didn't find manual configuration of all that to be all that difficult to learn. I feel like people get a ton of use from CRA when learning, and then are told never to touch the magic black box of CRA because it is just so hard. So they never do. And never realize that it isn't as bad as all that.
I do think it provides a great service for new coders, or small projects. So I do recommend using it in many cases. But I completely reject the idea that only 5 people in world are smart enough to set up their own build configs.
I didn't find manual configuration of all that to be all that difficult to learn. I feel like people get a ton of use from CRA when learning, and then are told never to touch the magic black box of CRA because it is just so hard. So they never do. And never realize that it isn't as bad as all that.
I do think it provides a great service for new coders, or small projects. So I do recommend using it in many cases. But I completely reject the idea that only 5 people in world are smart enough to set up their own build configs.
> But I completely reject the idea that only 5 people in world are smart enough to set up their own build configs.
There's a rather irritating tendency to frankly insult the intelligence of anyone that's not working on $BIG_NAME_PACKAGE, as though the people working on these libraries are from outer space and not (most often) rather regular humans who've ended up on particular career paths due to planning and/or being strategically positioned at the right time.
For some reason it's particularly prevalent in the JS community, where it especially does not make any sense considering that it's a very active open-source scene with plenty of people pointing out bugs and submitting fixes to popular packages every day. I wonder if it's a frontend web dev thing in general - it's common to see people make similarly hyperbolic statements about CSS (no, it's not that hard to centre a div, and even if it was it says more about you if you agonise over it every time you encounter it and not just, I don't know, save the working snippet somewhere and refer to it when you need it).
There's a rather irritating tendency to frankly insult the intelligence of anyone that's not working on $BIG_NAME_PACKAGE, as though the people working on these libraries are from outer space and not (most often) rather regular humans who've ended up on particular career paths due to planning and/or being strategically positioned at the right time.
For some reason it's particularly prevalent in the JS community, where it especially does not make any sense considering that it's a very active open-source scene with plenty of people pointing out bugs and submitting fixes to popular packages every day. I wonder if it's a frontend web dev thing in general - it's common to see people make similarly hyperbolic statements about CSS (no, it's not that hard to centre a div, and even if it was it says more about you if you agonise over it every time you encounter it and not just, I don't know, save the working snippet somewhere and refer to it when you need it).
> There's a rather irritating tendency to frankly insult the intelligence of anyone that's not working on $BIG_NAME_PACKAGE [...]
I apologize if what I said came across like that. I don't mean to insult the intelligence of people who want to roll their own build tooling, I just want to point out that doing so is a waste of time when somebody else has put in the work of building doing that for you. I would say the same thing to someone who wanted to build their own web framework instead of just using Rails/Django, or someone who wanted to build their own blog engine instead of using WordPress/Jekyll.
Your time is valuable. Don't waste it on writing Webpack configs.
Of course, if you're doing any of this to learn how things work, then more power to you! But if you're putting hand-rolled versions of popular frameworks and libraries in production, then you're doing a disservice to those who have to maintain those things after you've left your job.
I can say with confidence that most posters on HN (including myself) will do a worse job at setting up a build system than CRA. There are hundreds of contributors fixing issues in CRA, and all of them are really smart people. It's an open-source project with thousands of eyes looking at the code. I doubt that a lone developer working in a silo could come up with something better.
I apologize if what I said came across like that. I don't mean to insult the intelligence of people who want to roll their own build tooling, I just want to point out that doing so is a waste of time when somebody else has put in the work of building doing that for you. I would say the same thing to someone who wanted to build their own web framework instead of just using Rails/Django, or someone who wanted to build their own blog engine instead of using WordPress/Jekyll.
Your time is valuable. Don't waste it on writing Webpack configs.
Of course, if you're doing any of this to learn how things work, then more power to you! But if you're putting hand-rolled versions of popular frameworks and libraries in production, then you're doing a disservice to those who have to maintain those things after you've left your job.
I can say with confidence that most posters on HN (including myself) will do a worse job at setting up a build system than CRA. There are hundreds of contributors fixing issues in CRA, and all of them are really smart people. It's an open-source project with thousands of eyes looking at the code. I doubt that a lone developer working in a silo could come up with something better.
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.
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.
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.
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.
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.
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.
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.
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.
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?
This one for instance: 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.
If you need to use CRA behind a different publicPath in dev (behind a gateway) you can't and need to eject.
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.
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.
I 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.
I'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.
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.
"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"
Would you mind providing some examples?
It would be handy to know exactly what they are running into... so I do not.
Would you mind providing some examples?
It would be handy to know exactly what they are running into... so I do not.
If it's happened more than twice you should probably consider giving your current and future students information on how to handle the issues your previous students have faced. Going off the harsh language in your comment, your disdain for CRA may be showing to your students which may make you seem unapproachable.
> 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.)
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.)
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.
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.
Isn't it odd that the removal of --typescript in favor of --template isn't considered a breaking change?
It's not removed, it's just being deprecated. I would assume it would only be removed in 4.0:
> For TypeScript users, we're deprecating --typescript in favour of --template typescript.
> For TypeScript users, we're deprecating --typescript in favour of --template typescript.
You only run that when starting a new project, right? So no existing projects would break when it's actually removed, because they'd never run it again.
I think a lot of people have been waiting for this in order to start using the new optional chaining and nullish coalescing operators. Thanks to the Typescript and CRA teams for making this happen. This will be a nice quality of life enhancement.
Hmm. I’m a frequent user of cra but this release reads quite confusing. What are templates and why do I need them? Why are there 3 different package tools used (npx, npm, yarn)? What is all that babel config for? I have to be honest, the main reason I use cra is so that stuff is abstracted away, and this release looks like a lot of it is starting to “spill back out”.
Don’t want this to be purely negative though. I am a huge fan of cra overall and it has helped me immensely with setting up new projects and prototyping. Just hope the core simplicity will stay.
Don’t want this to be purely negative though. I am a huge fan of cra overall and it has helped me immensely with setting up new projects and prototyping. Just hope the core simplicity will stay.
CRA's default template gives you several files in `/src`. In the default template, most of those files are intended as examples:
- `index.js` is required as the entry point for the app
- `App.js` is the main app component
- `App.test.js` shows you can write a test for a component
- `App.css` shows you can import CSS files directly into the JS to have it included in the output
You can begin editing those files, or just delete all but `index.js` and start writing your own.
Many folks who have used CRA will just immediately delete those. Beyond that, some folks have forked the `react-scripts` package just to set up a different project source template.
Adding an option to specify a template means that other folks can now publish their own CRA-compatible project source templates and have them work with CRA right away. For example, I'm a Redux maintainer, and we could create a CRA template that already has a dependency on Redux (or our new Redux Toolkit package), all set up and ready to go without the user having to manually install them.
The different package tools mentioned in the release notes serve different purposes. `npm` and `yarn` are competing JS package managers. They both install and update packages from the NPM registry, with some different features available. `npx` comes with the `npm` tool, and is a way to quickly run CLI packages like `create-react-app` without having to explicitly run a separate "install this globally" command first.
- `index.js` is required as the entry point for the app
- `App.js` is the main app component
- `App.test.js` shows you can write a test for a component
- `App.css` shows you can import CSS files directly into the JS to have it included in the output
You can begin editing those files, or just delete all but `index.js` and start writing your own.
Many folks who have used CRA will just immediately delete those. Beyond that, some folks have forked the `react-scripts` package just to set up a different project source template.
Adding an option to specify a template means that other folks can now publish their own CRA-compatible project source templates and have them work with CRA right away. For example, I'm a Redux maintainer, and we could create a CRA template that already has a dependency on Redux (or our new Redux Toolkit package), all set up and ready to go without the user having to manually install them.
The different package tools mentioned in the release notes serve different purposes. `npm` and `yarn` are competing JS package managers. They both install and update packages from the NPM registry, with some different features available. `npx` comes with the `npm` tool, and is a way to quickly run CLI packages like `create-react-app` without having to explicitly run a separate "install this globally" command first.
Thanks for the breakdown! I find it really difficult to track everything that's going on in the react ecosystem. I realise for many people 'npx' is something that's been available for a while now but it's one of the many things I haven't had time to look at yet
I am using redux-starter-kit in one of my projects and I was curious about the "Redux Toolkit" package you mentioned. I have somehow missed the change of name, but I find it more fitting now. Highly recommended, even for experienced Redux users.
Yeah, we changed the name from "Redux Starter Kit" to "Redux Toolkit" because folks were misinterpreting the word "Starter" to mean that it was a CLI tool like CRA, or that it was only good for beginners. Didn't want the churn, especially since it was after RSK had hit 1.0, but we had enough people telling us "I didn't even look at it because of the word 'Starter' in the name" that it was clear that had to change. Fortunately, the feedback on the name change has been almost universally positive.
And yes, RTK is intended to be useful for both new and experienced Redux users [0], and we're now recommending it as the default standard way to write Redux logic [1].
See the RTK v1.0.4 release notes [2] for the details on the name change.
[0] https://redux-toolkit.js.org/introduction/quick-start
[1] https://redux.js.org/style-guide/style-guide#use-redux-toolk...
[2] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.0.4
And yes, RTK is intended to be useful for both new and experienced Redux users [0], and we're now recommending it as the default standard way to write Redux logic [1].
See the RTK v1.0.4 release notes [2] for the details on the name change.
[0] https://redux-toolkit.js.org/introduction/quick-start
[1] https://redux.js.org/style-guide/style-guide#use-redux-toolk...
[2] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.0.4
React Toolkit is so good, I've been following the advanced tutorial with TypeScript and it makes Redux so much cleaner. Thank you!
I hear you, but FWIW CRA continues to do a pretty admirable job hiding the complexity. I think it's fair to say that the 3 tools you referenced by name are elementary / required knowledge before working on a Node-based project, and it'd be impossible (or crazy) for CRA to try to abstract them away: `yarn` is a generally superior alternative to `npm`. `npx` is a convenient alternative to globally-installed packages.
> `yarn` is a generally superior alternative to `npm`.
I’m about 18 months out from last using it, but people were saying this then and it was, in fact, full of bugs and missing features. The company I was at kept starting projects with it because it was trendy, then switching to NPM when we tried to use a feature yarn didn’t have or lost an hour debugging some problem that turned out to be yarn-induced breakage. This was the consistent experience of about a dozen developers across several projects, most of whom were very enthusiastic about yarn, at first.
Maybe it’s much better now but, again, people have been saying this since it first came out and if it’s true, it’s a recent development.
I’m about 18 months out from last using it, but people were saying this then and it was, in fact, full of bugs and missing features. The company I was at kept starting projects with it because it was trendy, then switching to NPM when we tried to use a feature yarn didn’t have or lost an hour debugging some problem that turned out to be yarn-induced breakage. This was the consistent experience of about a dozen developers across several projects, most of whom were very enthusiastic about yarn, at first.
Maybe it’s much better now but, again, people have been saying this since it first came out and if it’s true, it’s a recent development.
I have the opposite experience, for our project once we moved to yarn it just works, we have not touched the config in close to a year.
I recall running into:
- Messing up certain cases of dependency resolution such that you'd get a different version than NPM would give you.
- Something involving not checking paths they should have been, that caused brokenness.
- Local package problems of several sorts—really any 1%-of-users-or-lower use case, and I'd guess "just fetch some packages from the NPM servers" is the sole use case over 1%, seemed fairly likely to have problems.
- All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn.
There were more but I don't remember all of them. My impression was that they implemented half the features of npm, did way fewer correctness and safety checks, crowed about how fast they were, and everyone crowned it as a superior drop-in replacement for npm literally years before that would be justified.
Mind I have no love for npm and don't much care what the command I run is called or who made it, I just repeatedly saw projects start on yarn then hit a silly problem the simplest fix for which was "use npm", while people were running around shit-talking npm and acting like yarn was some kind of miracle.
[EDIT] our projects were node, React, and React Native. I'd definitely believe it's possible use Yarn and never hit this if you don't happen to use a package that's broken in it and has only been tested under npm, or happen to step on one of the landmines, and maybe it actually is totally fine now, I just know people were claiming it already was and sticking their fingers in their ears when you told them otherwise back when it absolutely was not a suitable npm replacement yet.
- Messing up certain cases of dependency resolution such that you'd get a different version than NPM would give you.
- Something involving not checking paths they should have been, that caused brokenness.
- Local package problems of several sorts—really any 1%-of-users-or-lower use case, and I'd guess "just fetch some packages from the NPM servers" is the sole use case over 1%, seemed fairly likely to have problems.
- All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn.
There were more but I don't remember all of them. My impression was that they implemented half the features of npm, did way fewer correctness and safety checks, crowed about how fast they were, and everyone crowned it as a superior drop-in replacement for npm literally years before that would be justified.
Mind I have no love for npm and don't much care what the command I run is called or who made it, I just repeatedly saw projects start on yarn then hit a silly problem the simplest fix for which was "use npm", while people were running around shit-talking npm and acting like yarn was some kind of miracle.
[EDIT] our projects were node, React, and React Native. I'd definitely believe it's possible use Yarn and never hit this if you don't happen to use a package that's broken in it and has only been tested under npm, or happen to step on one of the landmines, and maybe it actually is totally fine now, I just know people were claiming it already was and sticking their fingers in their ears when you told them otherwise back when it absolutely was not a suitable npm replacement yet.
> - Messing up certain cases of dependency resolution such that you'd get a different version than NPM would give you.
NPM can mess up it's own dependencies, or give you different dependencies on different machines. It's algorithm is (was?) non-deterministic.
> - Local package problems of several sorts
I use yarn with lerna to keep a monorepo of local packages together, it works pretty well. At the time, npm didn't.
> - All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn.
Never ran into anything like this. Show me a package that doesn't work with yarn
Yarn gave npm some much needed competition and made npm improve a bit. Before yarn, npm didn't even have lockfiles. Having both is good, but I've just had less issues with yarn overall.
NPM can mess up it's own dependencies, or give you different dependencies on different machines. It's algorithm is (was?) non-deterministic.
> - Local package problems of several sorts
I use yarn with lerna to keep a monorepo of local packages together, it works pretty well. At the time, npm didn't.
> - All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn.
Never ran into anything like this. Show me a package that doesn't work with yarn
Yarn gave npm some much needed competition and made npm improve a bit. Before yarn, npm didn't even have lockfiles. Having both is good, but I've just had less issues with yarn overall.
> Never ran into anything like this. Show me a package that doesn't work with yarn
Been too long, don't remember. Happened more than once. Options were "debug package under yarn, and assuming there's a way to fix it without modifying yarn itself, submit PR to package's repo" or "just use npm".
Naïve search for 'is:issue is:open "npm works"' over yarn's ~2,000 open issues reveals some packages that don't work with it, pretty quickly. I'm sure npm has bugs too but we consistently and reliably ran into yarn problems that could be fixed immediately by switching to npm, on several projects. A browse through their issues more generally reveal tons and tons of broken features and edge cases, still, looks like, which is how it was back when I was using it, too.
If it's working for folks that's fine, but I think it's still a bad idea to give (especially) newbies the impression yarn's clearly the best choice.
Been too long, don't remember. Happened more than once. Options were "debug package under yarn, and assuming there's a way to fix it without modifying yarn itself, submit PR to package's repo" or "just use npm".
Naïve search for 'is:issue is:open "npm works"' over yarn's ~2,000 open issues reveals some packages that don't work with it, pretty quickly. I'm sure npm has bugs too but we consistently and reliably ran into yarn problems that could be fixed immediately by switching to npm, on several projects. A browse through their issues more generally reveal tons and tons of broken features and edge cases, still, looks like, which is how it was back when I was using it, too.
If it's working for folks that's fine, but I think it's still a bad idea to give (especially) newbies the impression yarn's clearly the best choice.
So interesting that a few years after Rust introduced the optional chaining operator, it's been filtered through the lens of many major languages out there.
I think Rust was the first to do it (if you don't count Haskell's more general do-notation). Can anyone confirm that?
I think Rust was the first to do it (if you don't count Haskell's more general do-notation). Can anyone confirm that?
Swift?
Or, depending on how you feel about sending a message to nil simply returning nil, Objective-C?
Swift's variant is much more modern, though, as it has the ability to inline assert.
https://docs.swift.org/swift-book/LanguageGuide/OptionalChai...
Or, depending on how you feel about sending a message to nil simply returning nil, Objective-C?
Swift's variant is much more modern, though, as it has the ability to inline assert.
https://docs.swift.org/swift-book/LanguageGuide/OptionalChai...
Rust had it before Swift did, I remember when the ? proposal came down the pipe to replace the try! macro and Swift didn't have it yet
[deleted]
I think C# (and VB) had it before Rust. My memory of the timeline might be a bit off, though. I know C# and VB got the chaining operator in 2015.
After some digging, I think Groovy got it first.
Here is a blog post from 2009 about it: https://mrhaki.blogspot.com/2009/08/groovy-goodness-safe-nav....
Cool, thanks for this. Rust/Swift's variant is arguably a little different (because it works with a sum type) but I think the influence is pretty clear here.
Coffeescript has that operator.
Am I the only one here that loves the idea of create-react-app but doesnt use it because it is almost impossible (or rather, was almost impossible as of a few months ago) to utilize features in webpack etc.
The whole idea of "you need to eject" and can only eject one time to install a package that allowed me to use JSX If/Else statements [1] turned me off to the whole thing. Now I have a custom project and just create new ones with cookiecutter
Im open to being wrong here, but the experience kinda sucked IMO.
[1]https://github.com/AlexGilleran/jsx-control-statements
The whole idea of "you need to eject" and can only eject one time to install a package that allowed me to use JSX If/Else statements [1] turned me off to the whole thing. Now I have a custom project and just create new ones with cookiecutter
Im open to being wrong here, but the experience kinda sucked IMO.
[1]https://github.com/AlexGilleran/jsx-control-statements
Use craco.
https://github.com/gsoft-inc/craco
I needed it to get CRA working in a lerna/yarn workspaces monorepo. Super impressed with how easy config is.
https://github.com/gsoft-inc/craco
I needed it to get CRA working in a lerna/yarn workspaces monorepo. Super impressed with how easy config is.
this is exactly what i was looking for, thank you!
You can use https://github.com/timarney/react-app-rewired to override anything in the default CRA config
Nope. My company ended moving off it because it’s not extensible at all. create-poi-react-app is a nice alternative, same functionality (and more) while using webpack chaining and allowing you to bring your own eslint config (or anything else).
I see comments praising they can now use new ECMAScript proposals, e.g., nullish coalescing. If you hadn't been at the mercy of an abstracted build tool, you could've upgraded your build system yourself. I don't like the idea of running my projects like that. If I want something in my project, I get it. There's none of this "waiting around" for it.
Yeah, it's such a huge failure on Facebook's part. It's completely unusable in an enterprise environment and I can only recommend it for small one-off applications. The tagline they use but is "convention over configuration" but it's really "convention without configuration". It's frustrating the amount of times you find a GitHub issue for a feature you're looking for and the answer from the CRA team is "well we've decided you don't really need it" -- even for things that are a simple one or two line config in Webpack.
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.