You don't need all those things, and for the most part you likely never did. Today I think most of it is legacy. A member of one of my teams recently wrote a node template for azure function apps, and when I reviewed it I asked them why they were using 20 dependencies when they needed 3. There was a lot of reasons, but the main reason was "that's what we've always done". One of these prevented updating to typescript 7 which is why I was reviewing it to begin with. A day later they're down to 4 dependencies that are actually being used for something useful.
SPA's and their frameworks still have their use cases. I don't think you can really get full "simplicity" when you have a lot of people working on the same code that goes into enterprise production. I do think that a lot of the more complicated stacks mainly exist because "that's how we've always done it". Which is frankly also a fair consideration if you're not in a position where changing it would generate a lot of value.
I find that it always comes down to people. The fewer people you are, the easier it is to make rapid changes. With a lot of people, and maybe people with very different backgrounds and skill-sets things changes. Change management isn't easy, and often the actual tech stack will matter a lot less than building a good team around it. You obviously still want to work toward changes and approvements, but switching a 100 people from their safe and overly complicated tech stack to something else will take a while. You'll also have to be damn sure it's worth it.
SPA's and their frameworks still have their use cases. I don't think you can really get full "simplicity" when you have a lot of people working on the same code that goes into enterprise production. I do think that a lot of the more complicated stacks mainly exist because "that's how we've always done it". Which is frankly also a fair consideration if you're not in a position where changing it would generate a lot of value.
I find that it always comes down to people. The fewer people you are, the easier it is to make rapid changes. With a lot of people, and maybe people with very different backgrounds and skill-sets things changes. Change management isn't easy, and often the actual tech stack will matter a lot less than building a good team around it. You obviously still want to work toward changes and approvements, but switching a 100 people from their safe and overly complicated tech stack to something else will take a while. You'll also have to be damn sure it's worth it.