Any codebase that is worked on by a lot of people tends to become over-complicated unless there is very good technical leadership (and even then).
When you are solo-dev in a project and run into some underlying problem[1] of your codebase you fix the problem. When you have a team the less-powerful[2] tend to work around it because fixing the underlying problem is not just a technical problem, but an organizational problem[3].
The same applies as a codebase gets older and bigger. The best I can explain is through a formula:
real cost fixing underlying problem = size of team * size of codebase affected by problem * nominal cost of fixing problem
Which makes this (in math terms) cubic (^3) while people scale linearly (*n).
Which is why when people compare technologies it is very important to also think about the "Pit of Success":
[2]: People new to the project, people less experienced, people who don't hold the big title (staff engineer, etc)
[3]: It requires talking and explaining things to other people, often very busy people. The bigger the company the more teams need to be kept in sync when big things change, there might also be some inter-department drama or arbitrary deadlines from different teams and so on.
[4]: A lot of the power of React is derived from ecosystem libraries. Where stuff you can do is technically possible with React alternatives, but not very practical.
When you are solo-dev in a project and run into some underlying problem[1] of your codebase you fix the problem. When you have a team the less-powerful[2] tend to work around it because fixing the underlying problem is not just a technical problem, but an organizational problem[3].
The same applies as a codebase gets older and bigger. The best I can explain is through a formula:
real cost fixing underlying problem = size of team * size of codebase affected by problem * nominal cost of fixing problem
Which makes this (in math terms) cubic (^3) while people scale linearly (*n).
Which is why when people compare technologies it is very important to also think about the "Pit of Success":
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
React and Svelte are very similar, but React it so much more powerful[4] people often misuses those powers causing them to become foot-gun.
[1]: Abstractions, APIs, code patterns, libraries used, etc
[2]: People new to the project, people less experienced, people who don't hold the big title (staff engineer, etc)
[3]: It requires talking and explaining things to other people, often very busy people. The bigger the company the more teams need to be kept in sync when big things change, there might also be some inter-department drama or arbitrary deadlines from different teams and so on.
[4]: A lot of the power of React is derived from ecosystem libraries. Where stuff you can do is technically possible with React alternatives, but not very practical.