Hacker News Reader

Comment by nicoburns | Hacker News Reader

React has been stable since ~2015, and there are no signs of that changing.

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.

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.

Disagree; the "done thing" in React has shifted since then (moving from class-based components and HOCs to functional components and hooks), and in the wider ecosystem, Redux is being abandoned in favor of more React native things like Context.

While React apps in 2015 probably still work with the newest versions of React, you can't put a 2015 React dev in a 2020 project and vice-versa as if nothing's changed.

Hooks are new but they aren't really that complicated. The junior developers on my team were more or less up to speed after a couple of hours reading the docs and a couple of hours implementing their first hook based component.

Our app is still using Redux, so I guess that one hasn't hit us yet (but there's also no real reason for us to update to a newer method).

I can assure you that Redux is not "dead" or "being abandoned":

https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

https://blog.isquaredsoftware.com/2020/10/presentation-state...

Sure, it's definitely _peaked_, because there's a lot of other great options in the React ecosystem these days. But, there's still plenty of good reasons to use Redux. And, with our new Redux Toolkit package and the React-Redux hooks API, "modern Redux" code is a lot different than what you've seen in the past, as shown in our new "Redux Essentials" tutorial:

https://redux.js.org/tutorials/essentials/part-1-overview-co...

If you use context, you'll just wind up rewriting flux, redux, Rx, Event, mobx, or whatever in what is likely a worse manner.

and in the real world react apps use countless npm packages, which get regularly deprecated as react versions move forward .. the real world churn in react land is most unfortunate

> in the real world react apps use countless npm packages

This is often the case in practice. But it's a pretty easy problem to avoid. Usually those packages simply aren't necessary in the first place.

I would say that the React ecosystem as a whole is in constant flux, which is what really matters.

How much of an ecosystem do you really need? For me the key component are a state manager (e.g. mobX or Redux) and a Router (e.g. React Router). React Router has indeed been quite unstable, but that's gotten a lot better over the last couple of years. But React and Redux have both been super stable.

As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant.

React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s

> react apps often have dozens of additional packages. And the churn on these packages is significant.

IMO that's just poor engineering and not an inherent problem with React. The app I inherited at my current job had many such packages. And we have indeed had to update/replace some of them. However most of them were implementing functionality which could be trivially replicated in "plain react" so we've mostly replaced them with simple internal components and are not anticipating having the same problem in future.

I agree, for a significant portion of the packages yet not all.

Regardless, the diaspora of packages is just common culture in Javascript in the wild. As a reference, I site leftpad. As a remedy I offer the saying 'its better to laugh than to cry'.. :)

I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.

Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.

I tried to upgrade a substantial codebase from vue 2 to 3 and hit a brick wall with Vuex early on.

Most of the code people have written in Vue 2 is compatible with Vue 3.

All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.

Actually React 18 is likely to have breaking changes due to Suspense. Specifically the deprecated methods that are currently prefixed with UNSAFE_ will likely be removed.

This is simply not true. React 15 is not compatible with React 16 and it can even take substantial effort to upgrade if you used componentWillReceiveProps (though which in hindsight could be avoided in the first place)

I did that migration on a very large react project (hundreds of thousands of lines). As I recall, after dealing with warnings for the later 15.x releases, the upgrade was seamless. They're also good about creating codemods to make the transition easier -- something somewhat rare in the world of software libraries.

But not all of your packages!

My opinion comes strictly as an indy dev with very limited time and resources. So, any breaking change is frustrating.

Can you run code written in 2015 on the latest version?

Not necessarily; just offhand I remember these: https://reactjs.org/docs/react-component.html#legacy-lifecyc...

Admittedly those are trivial renames, but they've been renamed as such because they're very likely to be buggy with async rendering.

bwahahahahahahahahaha

Reply on news.ycombinator.com