Is that true? Can you give me an example of what you're thinking of? I've used React since pretty much the beginning and the only "completely different" looks I can recall is class-based components -> functional components + hooks. And even that evolution was pretty comfortable and backwards-compatible.
If I was a full-time web-developer, I'd maybe be willing to live with the churn of the JS ecosystem, but as someone who enjoys software engineering and building fun projects, the churn is simply exhausting and a big turn-off. I spent a year doing a lot of intensive React + Electron + D3 + MobX and all the associated stuff (webpack, npm, node, etc) in 2018, and then at some point I realized its like being on a hamster wheel and you gotta keep going frantically just to stay up to date with the newest libs and toys and APIs and current group think. Meanwhile, a year spent just writing and learning good software in Python (for example), gains me so much more transferable skills to anything I touch as a software engineer in the future.
I still like the power of being able to make user-interfaces easily and there are plenty of things I enjoyed about developing web/electron-apps, but ultimately I was just turned off by how much continuing investment of your time it requires just to stay relevant in the field without imho adding any real value to actual software engineering skills.
Right, and that code still runs and compiles exactly as it did then, correct?
The fact that other tools move on doesn't mean you have to. Actually, out of what you just said, D3, MobX, and React all have not removed any of the APIs you could've used back in 2018. Did people maybe rewrite some tools to support hooks, and in doing so find that hooks were a more concise and readable solution? Yeah, they did, so we moved to hooks.
> a year spent just writing and learning good software in Python gains me so much more transferable skills to anything I touch as a software engineer in the future
How so? This is a complete non-sequitur. If you consider data science / ML to be the entirety of software engineering, then maybe you have a point, but since you even put (for example) beside Python it just looks to me like you hate JS and will pretend it's not software engineering so you can avoid it. Any time you've spent tweaking build systems or updating libraries for no reason is on you, not on JS.
Which, sure, is where a lot of the new goodies are going, but in enterprise land (where I recall working on apps that were .NET 2.0 and .NET 1.1 that were first written well after either was current and are still, AFAIK, being maintained, and on those platforms) writing apps with the still-fully-support class components and ignoring the newfangled options would be completely within the scope of normal approaches. Having new options doesn’t make something less stable, not supporting the old way of doing things is unstable.
> you gotta keep going frantically just to stay up to date with the newest libs and toys and APIs and current group think
AFAICT, there’s no active platform where that’s not true, if you want to stay up to date with the newest libs and toys and APIs and current group think.
In enterprise land, though, we typically (at least for any given product team, and often at a larger organizational level) tend to go to the opposite extreme: we plant our flag someplace that was out-of-fashion of the hipsters for years before we even started the project, and nothing that doesn’t actually break what we have built that happens after that really matters. Pushing things out of that rut often takes effort.