A good example is a tool like `create-react-app` (especially if you add TypeScript support). It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks!
It's also really really huge. Where I work, we mostly use ASP.NET with a few JavaScript libraries. A team made a new thing in React. The node_modules weight 276 Mb for a 2 Mb app. npm audit says that there are 11 vulnerabilities, but the package.json was updated 2 weeks ago (and this is with npm install, not npm ci). There are in total 1000 libraries. 165 of them are looking for funding, which means they could easily be the target of a malicious agent (take the repo, publish something new on npm obfuscated, extract credentials). I see the value of modern development tools, but this is just insanity, and going way too fast.
I used to be a huge fan of lots of small libraries updating often, but now that I'm in an enterprise context, it's hard to say the same. I wonder how people deal with this.
The joke gets worse!
Wait till you have to support this system over the upgrade paths for those 1000 dependencies of varying pedigree and funding, and React has changed their one true way often which effects those libraries many of which jut deprecate and you have to find alternatives.
Is there even such a thing? I know that there was class components and then function components and then hooks, but outside of that, the insistance on React being a library means that the ecosystem is very fragmented. There's CRA, there's Next, there's Gatsby. There are lots of different ways to do CSS. TypeScript? No TypeScript?
I wish there was a frontend framework focused on stability over time.
they don't, and just stick their head in the sand. I know i do!
I've never had a good long-term experience with tools that try to be or solve everything for me, and today I avoid them.
I've always found myself experiencing that same feeling, but I've come to realize that this is essentially impossible to avoid by definition. Any tool or system you're using that is built using abstractions must by definition have some limitations at the boundaries of those abstractions, and those limitations can only be circumvented by jumping across that boundary. The only real decisions you can make are which tools to use for a particular job.
For most single page apps, create-react-app occupies an abstraction level "sweet spot". Webpack is too low level and changes too quickly.
Conceptual complexity is of enormous importance to the usability of a tool. I build APIs for a living and have often needed to push back vociferously over things that would make code terser, but the underlying mechanisms harder to understand.
That said, I actually think codegens are often the right tool for the job - it removes a lot of boilerplate (at least from the developer needing to write it) but doesn't obfuscate underlying mechanisms - those are free for examination as needed.
Of course, the devil's in the details - if the codegen'ed stuff is pure spaghetti that defeats this benefit.
The worst, worst sin of all are frameworks that insert "magic" functionality. For example: name a thing in a special way and stuff will automagically happen to it? I can't think of a worse, more opaque way to design a system than rote memorization of incantation that reveal nothing about what's actually happening.
The less you know about how the internals work, the less you'll be able to intuit about what you can and can't change. For many people who just want to make "an app" this doesn't matter, but it also means that a lot of quick start setups optimize for particular approaches that are built on top of particular sub-sets of how apps are built. So people leave the experience knowing more about how a particular component library than they do about the language or the requirements of mobile, or whatever.
Or, to put it another way: increased complexity also increases the difficulty of investigation and modification. Making it easier to get an app 'somewhere' can make it harder for someone to understand what the app does to get where it's going.