I know that ecosystem fairly well, and have found it pretty effective to develop in. Compared to that, we have vanilla JS, which is okay for a thing or two, but awful to make a full SPA in. Or probably like 20 other web UI frameworks, all of which probably do the same thing as far as dependencies and have a learning curve for how to use them.
And what do we mean by "enterprise" here? The issue is the dependency chains and the maintenance issues that causes. If it was really "enterprisey", you'd think they'd do a better job of having a manageable dependency chain.
They may not need it now, but they choose this technology for a reason - maybe because they plan to develop it much more in the future. This does not mean they can't criticize its obvious flaws (which are a bit at odds with the "enterprise" part btw).
Usually, when you make a little project, you use the tools you know the best because you don't want to spend time coming up with something from scratch.
Also, it's a safe bet in case the project grows beyond the initial scope. You don't want to spend most of your time refactoring, do you?
Redux alone contributes a lot of boilerplate to state handling. Why is it needed? It has no benefits in small apps, it’s easy to abuse to destroy performance if a future dev isn’t cued in to the way Redux state needs to be normalised, and a React useReducer state handler is trivial to refactor to a Redux one later, if needed.
The same goes for TypeScript—how many interfaces does that app really have? Is it used in strict mode or just to type the most critical things?
