Hacker News Reader

Comment by davedx | Hacker News Reader

To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.

Redux is still by _far_ the most widely used state management library in React apps. By my estimates, around 35-40% of all React apps use Redux, and that's far more than any other state library in the ecosystem:

- https://blog.isquaredsoftware.com/2022/07/npm-package-market...

True but not for new projects. Legacy software has quite a long life span.

I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.

Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.

Has it occurred to you that maybe “state management” is not something you need a framework for?

Tell me you're not making complex webapps without telling you're not making complex webapps

The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily.

Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.

"State management is complex, so we used a framework to make things easier."

"Why use a widely popular, well-documented, battle-tested framework? Just have one of your senior devs build something over the weekend. This will definitely reduce complexity."

Like... I get what you're saying. But "build your own" is not a default answer for an extremely complicated software engineering topic (which, yes, state management is!)

FWIW, Redux literally _is_ a pub-sub/observer pattern implementation :) And the Redux core library _is_ extremely small.

But, that led to the community building hundreds of addon libraries for the same sets of use cases, which is what led us to build our official Redux Toolkit package to simplify standard Redux usage patterns.

This relates in no way to any statement from the comment you replied to.

Did you mean to reply to a different comment?

> [..] the most popular state management framework for React [..]

Quoted from the comment they're replying to.

> [..] maybe “state management” is not something you need a framework for?

Quoted from their reply.

Ah I beg your pardon. I read the comment in completely the wrong tone of voice.

To me it seemed like the comment was attacking its parent for investigating state management frameworks in the first place - when it in fact called out "no framework" as a valid alternative to any number of frameworks.

(I hope that made sense)

Exactly.

Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.

What were they using before?

I think Observables are much simpler to grok than some hundreds-line multi-file combined reducer/actions amalgamation.

I think React hooks are so much easier to write than observables. It provides similar functionality to observables, but without the added complexity.

What's interesting is why was it so widely accepted in the first place. It's not like boilerplate reveals itself at later stages, it's right there from the beginning. I think it tells a lot about the state of the industry.

What are people using now? Good old context?

Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.

Second time today that someone has mentioned React-query to me. Sign that I need to look that up finally

Reply on news.ycombinator.com