Comment by danabramov | Hacker News Reader

Comment by danabramov | Hacker News Reader

Parent Full thread

Are you using React and voicing your concern? Or are you making a guess?

Every three months might be too often for a tool like curl. In case of React, the community seems to be happy with the tradeoff between moving forward and keeping the old code working.

You might want to ask a few people who use React to draw the conclusions. I talk to a lot of people in the React ecosystem, and so far the feedback I heard is that updating React has been the least of their worries, compared to some other libraries in the ecosystem which are far less stable.

Personally, I updated a fairly large (~1000 modules) app from React 0.11, to 0.12, to 0.13. After the ecosystem catches up and libraries release compatible updates (if they need to), it always took less than a day to upgrade. Doesn’t seem like a big price to pay for avoiding stagnation and actually improving the library.

And I wasn’t even using codemods which React team ships (and widely uses internally at Facebook). Codemods just convert your code through most of the API changes automatically.

> Are you using React and voicing your concern?

Yes.

> Every three months might be too often for a tool like curl.

Why should a tool for creating dynamic HTML be held to a lesser standard? I wouldn't expect the level of stability that curl has yet, but I would expect it to be an eventual goal of the project. The reason why we build abstractions is so we can eventually stop worrying about a problem; that can't happen without stability.

> You might want to ask a few people who use React to draw the conclusions. I talk to a lot of people in the React ecosystem, and so far the feedback I heard is that updating React has been the least of their worries, compared to some other libraries in the ecosystem which are far less stable.

That's because you talk to other enthusiasts who are happy about changes. Try asking people outside of the React Slack channel for a wider perspective.

I've had people complain on my projects about upgrading apps using APIs deprecated 2 or 3 years prior. And I feel genuinely bad about it, because if they are having to justify spending 3 or 4 days refactoring their app (which is hard to do in a lot of companies) because I made an API mistake 3 years ago... I feel bad about it. We should strive for better stability.

But HTML/Javscript is a moving target in itself. HTTP moves slower. So an HTML library is by it's nature going to have to move faster than an HTTP library.

Thank you for your feedback. Would you please name specific API changes in React that were problematic and forced you to spend more than a day migrating? This would help me better understand the issues.

You also have the ability you like, you know, not upgrade. Of course you might miss out on some of the newer and fancy features that come with the upgrades, but you still always have control.

If React 15 was good enough for you when you started using it, it doesn't necessarily fundamentally stop working when React 16 ships.

>If React 15 was good enough for you when you started using it, it doesn't necessarily fundamentally stop working when React 16 ships.

No, but your project is seldom 100% finished either. So as you do minor changes to it, and want to use some new lib, you find out that it's not compatible with your old version.

And libraries stop get maintained too -- and when you finally try to make the conversion it will be harder the longer you have waited, because aside from porting your code to all new React stuff, you'll also need to find replacement for all those libs at once (not piecemeal, which would be the case if you kept the project up to date faster).

This could also happen for all kinds of external reasons too -- e.g. you use a third party service and they change their API. Or you update your OS and your old libs suddenly stops working. Or a browser deprecates some feature (like Object.observe that Google warns that it will be removed on March).

Reply on news.ycombinator.com