Hacker News Reader

Comment by ryanbrunner | Hacker News Reader

I guess this depends on your definition of "stable". Sure, React code written in 2015 will still work, but it's hardly the "modern" way to write React and if your organization's code was written entirely in 2015, engineers will probably be clamouring to rewrite it.

Taking the somewhat-arbitrary but reasonable standpoint that "stable" means that there aren't any major architectural changes required to bring a codebase up to modern standards, I think the best you can say is that React has been stable since hooks were introduced in Feb 2019. So about a year and a half of stability, which isn't horrible but it's a far cry from stable since 2015.

View on HN

The key thing for me is that old API is not deprecated, and the React team have publicly stated that they intend to maintain it indefinitely (and indeed are still updating it to work with newer React features).

At $DAYJOB we have no intention to rewrite our older class based code to hooks (except where we're otherwise making significant changes to that bit of code), and indeed we're still writing some new code in the class style.

If you feel like you need to upgrade then I think that on you, not the framework.

Apparently modern housing uses PEX water pipes, but my house has a mix of PEX, iron, and copper pipes. The water flows just fine. I'll probably rip out the iron and copper eventually when I do a major remodel, but I'm not stressing about it.

Agreed with "the modern way" to rewrite React code. Not simply for the sake of keeping current with version changes, but for one, to make sure your engineers are not constantly switching mental models between React Classes, HOCs, and Effects.

Another reason is the ease and speed of online documentation/resources. We all use StackOverflow to get answers and insight into problems we face on a daily basis, and as the framework (or library) progresses, the majority of Q&As adopt it, giving us a wealth of resources at our disposal.

Is the mental model switches between classes, HOC's, and effects really that taxing? Rewriting your code to match the current framework flavor is really less exhausting?

One time work to get knowledge outside your head vs mental notes for context switching while you code? For some people/projects, the first one would be much easier.

Personally I don't find hooks vs. classes much of a context switch. The mental model for the component lifecycle is more or less the same, it's mostly just a different surface syntax (there are a few extra rules for hooks like not putting them in conditionals, but you'd have those in a pure-hooks setup too).

If you understand each approach well enough they aren't context switches at all - they're just different tools for solving a similar problem. If anything, understanding each of them gives you a better understanding of the approach your team has converged on.

Reply on news.ycombinator.com