Hacker News Reader

Comment by dawnerd | Hacker News Reader

I second you on that. The number of times I've had to rewrite code because a framework decided to break everything with little warning.. I don't even want to think about it actually. I get wanting to make code better but gesh people, do some planning and figure out a direction to move a project.

Also it seems JS devs don't understand semver either. Massive breaking changes in patch or minor versions are just evil.

View on HN

React is actually pretty decent in terms of upgrading. Also, the idea of semver is more widespread in the JS community and there are things like Angular commits and tools like commitizen.

It has a tick-tock pattern so that you can upgrade and having time to fix the warnings.

The API changes are carefully crafted.

Sometimes there are even migration tools to help you upgrade.

There is just some kind of internal resistance increasing the major-version for a breaking change, especially when that change is just tiny.

I have published a library myself and experienced it, going from 2.x to 3.x to 4.x.

After you just do it for the sake of semver though, the resistance vanished for me.

And the second thing: Never use 0.x.x versions, I think those should have been omitted from semver completely, as they circumvent the entire concept.

Big name libraries and frameworks like React and Angular manage things relatively well and in a similar way to other frameworks in other languages (you could argue about AngularJS -> Angular but if you worked with both frameworks you know that AngularJS was a dead end approach designed for a completely different stack and it just didn't make sense to maintain backwards compatibility or maintaining that dumpster of a code base past it's EOL).

A problem in React ecosystem is that it's a rendering library not really a webapp framework so you need to use community provided libraries to fill in the gaps. Those libraries are often maintained by an individual so it's unreasonable to expect corporate SDK approach to development, but unfortunately it leads to a lot of abandonware and rewrites, especially since JS is not very maintainable and it's often easier to rewrite something than to pick up someone else's code.

Which core web app framework feature’s biggest 3rd party React library has been abandoned in the last few years? Or extensively rewritten to the point of seriously effecting end using programmers?

I am relatively new to React. Perhaps all of this happened 3 or more years ago.

I know React Router 4 was released in mid 2017. Perhaps I was too new when I looked over the changes between 3 and 4. It didn’t seem as drastic as the general opinion that JS changes like crazy. I looked at the migration guide again. Still doesn’t look too bad. Maybe it would be in a large code base.

I am developing with React and TypeScript every day for the past 5 years. Everything I did then works now, not a single line of code needed to be changed. There are new ways of doing things that I am extremely happy with (Hooks, advanced types), but the old way is not even deprecated yet.

I'm surprised that you don't see the changes between RR3 and 4 as drastic. It's a completely different API, and unsolved a problem which had (admittedly imperfect) solutions -- kicking off data fetching prior to navigation.

I try to resist hyperbole, but if it wasn't for the brand value of owning the name "React Router", it should (or would) have been released under a different package name.

react-router, react-router-redux, immutable.js was dead at some point when the only dev maintaining it left Facebook (AFAIK, I don't know if it got resurrected since) and people were just moving to immer.js. These are just on top of my head stuff that I had to replace when starting new projects because I didn't want to start a new project on potentially unsuported libs, there were more but I can't remember the names exactly - been a while since I was boostraping a new project.

I've had similar experiences with JS libraries, but not so much with React. The React team are much better at managing to keep things backwardly compatible than most.

I really like the React approach to upgrades: if your app works with version N with no warnings, it will work with version N+1. https://reactjs.org/docs/faq-versioning.html

Agreed, I'm fairly new to React this year and while it's been a rough learning curve for me it's nice how stable it is considering some of the example code is pretty old and it still mostly works just fine

From my experience, I think it's the total opposite. Airflow and even Python3 itself breaks on minor version.

Reply on news.ycombinator.com