Lots of assumptions. And they're all based on the fact React must be some all-encompassing framework, like all other frameworks are or have become, and there's no other way to organize your app, possibly, unless it's dropped from above, from the framework, and is intricately interwoven and coupled with it.
But there's another option: don't use React as a framework, use it as a library. And do your modules/components/reuse/fetching in your own plain code, while using React as a display layer. You don't even have to use React for the entire UI.
> Lots of assumptions. And they're all based on the fact React must be some all-encompassing framework, like all other frameworks are or have become, and there's no other way to organize your app, possibly, unless it's dropped from above, from the framework, and is intricately interwoven and coupled with it.
This is a silly argument to make. People don't want to onboard onto a myriad of little reinvented wheels just to put together a GUI. This is well known to be a major mistake, and the root cause of failure of countless projects.
People are paid to deliver features and fix bugs, and not to peruse through npm like they are playing Pokemon. React solves their problem by solving developers' problems. Don't you understand the value of using a standardized tool that answers all your problems?
People are paid to deliver features and yet the forums are full of why this and that is annoying in React and how version X.Y.Z is replacing it with something else that will be the next annoying this that people in the forums will discuss. I sense lack of alignment between intention and results here.
Knowing how to architect your app remains important, and once you know it, it's trivial. For those who refuse to learn it because they deem it a gargantuan task, frameworks will keep trying to provide a "generic" solution, but a "generic" solution is by necessity overcomplicated, overengineered, and bloated, because it's trying to address EVERYONE's concern and specific needs.
At no point in time will a monolithic "everything solution" be simpler than a specific modular solution to a specific modular problem.
React started with the promise of simplicity, and being a library, not a framework. Somewhere along the line this ideal was lost, this happens often. And it happens often because many small elegant solutions start with the intent of replacing the status quo bloated behemoth framework that everyone hates. What they don't realize is that with lack of understanding of why frameworks end up like this, this is the fate THEY will share one day. Entropy is a b**ch.
> People are paid to deliver features and yet the forums are full of why this and that is annoying in React (...)
Online forums dedicated to frameworks are filled with questions on what the framework does and how it works. No news there. What did you expect?
> Knowing how to architect your app remains important, and once you know it, it's trivial. For those who refuse to learn it because they deem it a gargantuan task, frameworks will keep trying to provide a "generic" solution, but a "generic" solution is by necessity overcomplicated, overengineered, and bloated, because it's trying to address EVERYONE's concern and specific needs.
I'm sorry, you typed a lot of words to actually say nothing. So you don't use all features provided by a tech stack. So what? That is not bloat. Writing software is not a game of bingo.
Also, reinventing the wheel when a fully working and tested wheel is already available is a very dumb mistake and a fundamental failure in the decision-making process.
> React started with the promise of simplicity, and being a library, not a framework. Somewhere along the line this ideal was lost, this happens often.
I don't think this is remotely true in any way. Undoubtedly React greatly simplifies the work of putting together working and full-featured SPAs. The concept is so good and so extensively proven that React is already being used to develop native GUIs in desktop applications.
Your comments reads as if you're tilting at a React windmill. It's ok if you like vanilla JavaScript, but you're not being honest with yourself if you're failing to understand what problems React solves, how well Reacts solves them, and why the whole world has basically standardized around it.
> annoying in React and how version X.Y.Z is replacing it with something else that will be the next annoying
Interestingly enough, React is probably the only major frontend framework that is obsessive about backward compatibility.
I had to pull a component from an internal project into my codebase recently. The component was still class-based. Worked without a hitch in the modern hooks-only code base.
How do you share data fetching logic across components
How do you share a common UI functionality like toggling states, starting timers, across components?
People are now more concerned about clearly writing business logic while stiching together React lifecycles methods, instead of the other way.