And any book older than that is useless due to class syntax or predating hooks. Just 3 years to turn a resource into a door stop.
In that time, the knockout parts have kept going strong. The react parts have seen three different paradigms ( React classes, Functional react with redux, React Hooks ) and still hasn't fully settled down given there's also churn in the CSS-in-JS space.
The very occassional time something in the remaining knockout parts need fixing, it's just a harsh reminder that it worked fine.
I'm fairly sure the react portion is still not even on the very latest version of react because some other dependencies are stuck on older versions and they themselves have breaking "API changes" (i.e. complete rewrites with no semblance to the original ).
As someone here also said, maintainers in the JS/TS ecosystem appear to have no respect for their users.
It might sound entitled, but sometimes not completely rewriting your framework's API to a completely incompatible one is a better choice. Even if that means putting up with a slightly worse API than you'd like.
I guess everyone moves so fast that there's a fear that sticking on the old API would just lead to dying off at the hands of a new upstart with a smoother API.
But the alternative is a constant abandonment of projects. If a major version change requires a complete re-write then really the new version is a new project entirely that's re-using the namespace and maintainership.
But perhaps emberJS fell away precisely because it didn't rewrite itself to stay "modern". Maybe this is a "worse is better" situation where the world optimises for the wrong things.
"Has had a mostly stable API for a decade" just isn't something people select for. If it were, then things like ASP.NET would be far more popular.
Meanwhile they've deprecated parts of the class components.
- https://github.com/krausest/js-framework-benchmark/pull/1835... - https://github.com/NullVoxPopuli/markdown-table-viewer - https://github.com/NullVoxPopuli/package-majors (older, needs update, which i can do pretty quickly if i remember to do it)
JavaScript itself barely changes - it's the flavor-of-the-month frontend frameworks that do. What language feature is commonly used now that wasn't 5 years ago? Some nicer builtin Array methods I guess?
There's a lot of dislike on here for Typescript as a backend language. But the difference with the frontend world with its dozen everchanging frameworks is striking. On the backend side, most projects don't even use a framework, and for those that do basically all of them use the same one (NestJS). And the rate of breaking changes on that has been much lower than something like React.
Of course, many will say that this lack of industry-wide adopted framework in itself is what they dislike about it. But it's hard to settle on that golden mean inbetween both extremes when it's the most popular language in the world (in terms of "Yearly new LOC going into production"). Python makes for a good contrast, with a dozen popularish backend frameworks. Not sure if that's really a better situation to be in, there's pros and cons.
The javascript language itself hasn't really had a breaking change of note that I can remember in the last 15 years? It's just expanded its API from years and years of browser implementations trying stuff and trying to get to an actual standard. HTML5/ES6/CSS3 brought a new kind of baseline sanity to the whole thing. That's not to say it's a perfect language without quirks, but to say it keeps changing is just not even accurate at all.
python has version evolution, C++ has version evolution, they kinda all do...
This isn't true.
ComponentWillMount and related methods were deprecated and then removed.
Yes, they allowed an escape hatch of UNSAFE_ComponentWillMount etc, but that still requires work to make it compatible, so it definitely doesn't "[work] perfectly well".
On the app development side, we dealt with 3 major overhauls of PrimeNG's style system before we decided to invest in a custom library just to eliminate the risk of future upgrades. It took us 6 months to migrate our Angular 9 app to 18 because of the PrimeNG dependency. Granted, it's a massive application and they didn't maintain it properly, but I'd hardly call Angular stable regardless.
And then you have the Vue composition API, which was a major shift from Vue 2.
This isn't to say that React has been perfect. Depending on your stack, there are certainly a fair degree of breaking changes (looking at you, Next.js and react router). But that is far from abnormal in the JS world.
I take it you didn’t have to deal with porting an AngularJS app to some other framework, like Angular 2.
At my company I mentioned using it in passing to our cto as we were discussing a project to move our core web app from angular to react, and he laughed saying "maybe if this was 10 years ago!".
Sorry there was hostility when you were around. We try hard to keep hostility out and keep everyone civil now a days
Yeah.
Last year I realized in my 10 or so years using Node I've changed my stack so many times (Express, Hapi, Fastify, Hono, Sequelize, Objection, Prisma, Drizzle, Mongo, Fauna, Postgres, Firebase, etc etc). So much time wasted.
Surprisingly, on the frontend I've found stability with Svelte. I've been using for 4-5 years now and still very happy with. I also love runes.
Sadly the Ember team made some strange decisions in the beginning and it wasn't easily grokable compared to regular JavaScript (most of that has been fixed now, though).
This is all to say that whether or not it's JavaScript doesn't really matter, compared to the stability of the API.