My bigger concern is that I don't want to become a passenger rather than the driver of my environment and build pipeline.

If you ever want to have more control, you can "eject" & customize however you like.

Unless you’re doing something so completely customised (and even then, ejecting from CRA is a blessed path), why WOULND’T you use CRA?

It's worth noting that CRA is pretty complicated. My home-rolled webpack configs are significantly simpler than ejected CRA apps. If you're going to be making significant changes to the configs it's going to be a lot easier with a custom project.

Once I ejected it took a little hacking to get the index.html to work with handlebars cause I like to render a bunch of data and other stuff server side for speed optimizations.

Now I use the same web pack pipeline CRA ships with and just point my server to serve static files from the build folder. I’ve removed the server component and now just have the script watch and build. I don’t believe in SSR for react and prefer handlebars for most things server side so this workflow suits me well.

The backend I have been working on for over a year, with DB, lots of random libraries for functionality like image processing, crypto, error capturing, SFTP etc has fewer liens of code than the very basic project structure to get started with React.

Not 10 years ago I would have been debating if my dom actions for a touch slider were too much computation. Now? Why send HTML at all? We can make it out of javascript!

CSS animations were a boon because we didn't have to do any of that JS calculation, mmm precious pragmatism. What's that? You want the background to be a real time generated animation in canvas? I know just the tool!

I am glad we seem to be at a point where we can do it all performantly enough. But I do have to wonder how we got here so quickly.

Well, sort of. The problem is, if every web app assumes they can squueze whatever resources it can, it basically reduces your overall performance (and - if you are mobile - your battery life). It wouldn't be a problem if it was about apps actually requiring these resources (number crunching and other computationally intensive tasks). But we are talking about mundane tasks such as displaying a GUI here! It's just laziness on the part of everyone involved, and the end user suffers most.

I'm not saying React couldn't be better but it is super popular and enables a lot of applications by a wider range of developers even if it is a more bloated.

Just like C++ vs. assembler.

React vs HTML/CSS/JS is a stupendous difference, and the barrier to entry, IMO, has gone up rather than down. At the start you basically have to be told what to do, and eventually you have some control over the output, if the tools you are trusting continue doing their job. Most people will never learn how the tools they are using actually work, and the massive surface area required to cover for this understanding is a big deterrent.

LoC is the wrong benchmark. In C++ you link against a large set of libraries that have already been compiled to binary, hiding the LoC. glibc source alone is 10k files.

Javascript libraries are source instead of binary. What's the problem?

The React CD takes a minute and a half longer than the backend one, and the back end one has testing and libraries of its own to pull as well.

Some of this comes down to SCSS, Babel etc, but most of it is built into CRA anyway

Also modern compilers condense C++ down pretty well. You can write something on godbolt.org and see how much waste there really is. You might be surprised.

Gets a lot better when you're visiting lots of such pages, then you have a million versions of each library in your cache.

Edit: For full transparency, this is the breakdown:

index.html = 1.37KB

main.hash.chunk.css + 2.hash.chunk.js + main.hash.chunk.js = 887B

logo.hash.svg = 3.2KB

logo192.png = 5.47KB

My biggest issue is with people pulling in dumb libraries on npm that seem to live on someone's self hosted server though, so some branches will CD just fine, while others don't, and then I have to troubleshoot why something completely out of my control isn't working. Ugh

1. React targets a rolling release platform which keeps on changing. On top of that, most people are not always on the latest version. If you are targeting something like an enterprise, you'd be stuck with IE.

2. React also has to run on 3 implementations of the web platform (Chrome/v8, Firefox/Spidermonkey, Safari/WebKit) which have no "obligation" to follow a standard. Many (Safari) can have enormous delays in deploying features to the public at large. Unlike Java, JS devs (especially front-end) don't have the ability to enforce a runtime platform or else they risk loosing users to their competitors. So you have to transpile code to run on browsers which doesn't speak the latest syntax.

3. JS also has enormous backward compatibility.

4. JS decoupled most of the quality-of-life features from the core language. What is generally part of the compiler or IDE (in case of Java/C++) are separate libraries that have to be manually installed by the user - so you see these huge npm installs for each project. No language escapes from this. In case of Java, all of this is hidden under the install size of eclipse/intellij. Though I do agree, that in some cases, JS devs have taken this modularity to the extreme (Specifically the thing that happened with left-pad)

5. Then there's the problem of how your frontend is tightly coupled with the product. How your frontend is built, performs etc determines your search ranking, your user retention, your customer experience. All of this directly defines your revenue.

Web as a platform is a wild beast. It's much more complex than we ever expected it to be and CRA does put a balm on all the pain points.