Comment by ggregoire | Hacker News Reader

Comment by ggregoire | Hacker News Reader

Parent Full thread

While I also think react-query should have kept v5 compatible with the v3 API (even if the new API is better, keep the old one optional, at least for a while), the migration is fairly easy and quick to do, and more importantly, it's not mandatory at all. I still have apps running v3 and v4 without any issues. Also, v3 to v5 is a bump of two major versions, it obviously implies breaking changes [1] (can't tell for Go but this happens in most part of the industry, see for example Python v2 -> v3, SQLAlchemy v1 -> v2 or psycopg v2 -> v3) and it's not like they release a new major version every week.

As someone who do a good amount of frontend dev, I feel like the "dependency management fatigue" sentiment, which is very common on this forum, is way too much inflated. Just keep your dependencies to a reasonable number, pick solid dependencies that don't break their APIs every year, and don't upgrade just for the sake of it. Like you surely do with your backend environment too.

[1] https://semver.org

The thing with the react community is that this constantly happens with random things. You cannot at all compare python v2 -> v3. The react community has 10 python v2->v3 situations in any given year. The only reason why it works, is that Facebook and by extension the react community think it's okay to hire massive Frontend development teams.

I've often felt this is the other way round: Facebook hired a massive frontend team, and therefore they have to continually create work for themselves.

The point where they re-centered React around a bad half-implementation of Objects, in a language that already has an OO system, was when I decided they were out of real problems to solve (or didn't know how to approach those real problems—do Forms still suck in vanilla React, without an add-on library or two?) and on to pure employment-justifying and CV-building.

And, more power to them, but at that point I'm not going to willingly rely on the project for anything.

> do Forms still suck in vanilla React, without an add-on library

Did they ever? Wouldn't we just do <form onSubmit={handleSubmit}> and then in the handler we just grab the FormData, send it to the server, get back the response, then update whatever? Doesn't seem like it should be that hard?

Nah, they had real problems that React solved. But most applications aren't Facebook and don't have the same need for this.

React v1 solved a real problem, but perhaps didn't really need 17 subsequent major revisions with another on its way? But that's the different cultures around this discussion. The Javascript community generally seems to subscribe to progress at all cost, which the earlier commenter attributes to exceptionally large teams like that at Facebook trying to find work to do, whereas the Go community generally subscribes to the idea that it is okay to be "done", clamping down on the extent of any future iterations.

To be fair the first major release was 15.0. So there has been there major revisions since then, not 17.

> The react community has 10 python v2->v3 situation in any given year.

That is not my experience. Maybe you could share with us some examples?

My most important dependencies, after React itself and TypeScript, are react-router (which released v6 in 2021) and react-query (which released v5 in 2023). I don't remember other major breaking changes in recent years, at least with the dependencies I'm using.

Eslint version 9 has been causing some headaches, as it broke all existing plugins.

Why did you upgrade?

Because everytime I perform NPM operations I'm slapped in the face with `This version is no longer supported.`.

Yes, we do maintenance contracts and anything react is really costly to keep up to date. You have enormous churn just to keep existing functionality. Super hard to sell that you need like 30 days a year just to keep you app live workable

Reply on news.ycombinator.com