You have misunderstood the point. I'm not saying "stop creating new frameworks". Create anything you want, I don't care.
When I am talking about "settling down", I'm talking about the people that implement real systems for businesses to use. Those people have to make decisions on the technology they're pushing.
If those people can't settle on a stack and keep changing their minds on how to implement a user interface, somebody has to pay for that. This is akin to a "little fire" in a very real sense - it's burning money that could be used otherwise.
So telling me that "I don't have to use it" is besides the point. I don't run the whole show by myself. Developers need to be reasonably comfortable with their stack. If you are using <outdated stack X> but the whole industry is shifting towards <shiny new stack Y>, people will just quit on you.
Businesses pay to solve business problems, not change frameworks. The majority of software dev requires long-term decision making, commitment and support. Developers who can't solve problems because they're too busy chasing the latest framework aren't going to be getting much work.
People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
> Developers who can't solve problems because they're too busy chasing the latest framework aren't going to be getting much work.
That's not really how hiring works. Nobody is going to put "I failed to get anything done because we re-wrote everything in Svelte" on their resume.
> People will experiment, and it's good for the industry to have new innovation, but there's really not that much danger of constantly shifting tech stacks unless your team and leadership don't know what they're doing - and if that's the case, you have bigger problems then the tech stack.
If you're switching a tech stack, by definition, you don't really know what you're doing. You're treading in unknown territory. You're spending real money for the promise of hopefully increasing productivity in the future. You are speculating.
I'm not saying this is a risk you should never take, there's a downside to never switching stacks too. The idea that you just need the right team and everything will be fine is a fantasy.
I'm saying that people dont constantly switch. It's not that common at all, despite what you might hear in online discussions. And it's usually because most of these projects have real timelines and deliverables, along with a team of people who aren't interested in rewriting everything either.
Of course there are a few teams (even in praised companies) that chase the fad, but they're the sames ones that do things like use CQRS and Kafka for a basic CRUD app.
You're saying people don't constantly switch, but even if they did, it wouldn't be much of a problem unless they don't know what they're doing.
Well, fair enough. I never claimed that businesses switch stacks "constantly" anyway. Still, at the industry level, there is constant flux - much more so than on other platforms. Unless you use one of the big players like React, chances are your framework of choice won't last and become legacy software quite soon.
