>It's kind of weird to me how programmers (especially of libraries like that) aren't more careful about introducing breaking changes, since the work needed to be done afterwards multiplies really quickly.
Programmers, generally, always aim to do that.
But the JS framework world for whatever reason has this constant obsession with reinvention. I honestly think it stems from a sort of inferiority complex that FE devs had in the the 2000s/10s which led to every single library feeling the need to invent new words to describe some CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart. So stores became "reducers", promises became "thunks", and macros became "runes", and lots of FEs got to high five themselves and add that stuff to their FAANG promotion packets while we wallowed in their mountains of meaningless abstractions in the name of "doing things The Right Way" like FB and Google.
That seems like a comment made with an outsider perspective. Various front-end libraries keep changing APIs simply because the web and related technologies keep constantly evolving.
When was the speed of change fastest and why? During 2010s, because usage of web/apps for everything exploded and browsers started to add features that designers and developer needed. If your CSS/UI library doesn't support for example CSS grid, you do what - not upgrade it and won't use modern grid at all? That's just a silly attitude.
> CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart
That maybe true, but 1) not only FE developers do that, 2) it's orthogonal to the actual reason I stated above.
Based on the amount of churn almost everywhere, I disagree with it seems like most are trying to aim to do that. I've been hit by similar issues (across multiple versions) in Python, Rust, Ruby, Go and bunch of other languages too. But then I'm comparing other ecosystems to Clojure which actually aims for interface stability, so maybe an unfair comparison.
Programmers, generally, always aim to do that.
But the JS framework world for whatever reason has this constant obsession with reinvention. I honestly think it stems from a sort of inferiority complex that FE devs had in the the 2000s/10s which led to every single library feeling the need to invent new words to describe some CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart. So stores became "reducers", promises became "thunks", and macros became "runes", and lots of FEs got to high five themselves and add that stuff to their FAANG promotion packets while we wallowed in their mountains of meaningless abstractions in the name of "doing things The Right Way" like FB and Google.