Live data from Hacker News

The new wave of React state management

frontendmastery.com

21–30 of 310 posts

Re: The new wave of React state management

#21
post #2

Mobx solved all of the state problems properly a long time ago.

Agreed! I'm surprised at the comprehensive work going into researching the history of state management in this article while completely missing MobX.

What problem does MobX not already solve?

Re: The new wave of React state management

#22
post #4

The "state management problem" appears to be an invention of React. This didn't use to be a problem with MVC. The state lives on the server. When state changes it should be persisted on the server immediately (in case the user unexpectedly closes the browser). On the client all you need is a cache. With MVC, each page is more or less independent. Each page gets the data it needs from the server (through a client-side…

Your causation is reversed.

People demanded more interactive web apps, which led to more stateful UI, which led to React.

In the case of Facebook, the motivating app was Ads Manager — an enormous, highly interactive single page app for advertisers. You couldn’t build something like it with HTML + server endpoints; in the pre-web days, apps with this kind of complexity would be desktop apps.

Google Docs, Google Sheets, Maps, Spotify — these all have a huge amount of client-side state. You can’t represent that state on the server without making the UI unusably slow. The need to build these kinds of apps in a portable way led to complex state, which React tried to address (so did Angular, Ember, Backbone, etc.).

Re: The new wave of React state management

#23
post #4

The "state management problem" appears to be an invention of React. This didn't use to be a problem with MVC. The state lives on the server. When state changes it should be persisted on the server immediately (in case the user unexpectedly closes the browser). On the client all you need is a cache. With MVC, each page is more or less independent. Each page gets the data it needs from the server (through a client-side…

I used to think the same thing until I considered that single page app development is really just a reinvention of thick clients.

When you look at an SPA as a thick client state management is a natural thing as it was in Java swing and WPF and Windows forms and other stacks beyond my knowledge

Re: The new wave of React state management

#24
post #15

After reading the "Grug Developer" article recently, I've been thinking of frontend development as "The Plane of Eternal Complexity Demons".

This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input devices like pens, keyboards, mice, etc that must be interpreted to have a semantic meaning. Often there are hundreds of API routes (event handling elements) on screen at once in a complex application. UI engineers are perpetually frustrated by this complexity, and so some small percentage look for better ways to handle these issues.

Of course it’s best to avoid UI programming entirely, but in many domains it’s necessary.

Re: The new wave of React state management

#25
post #2

Mobx solved all of the state problems properly a long time ago.

Agreed! I'm surprised at the comprehensive work going into researching the history of state management in this article while completely missing MobX. What problem does MobX not already solve?

All cited frameworks solve the problems. Article is more of a survey. It’s a pity to miss Mobx while discussing proxy/mutation API in Valtio.

Re: The new wave of React state management

#26
post #14
post #12

Earlier quoted context omitted.

This is true until your customers complain that your UI is super slow. You realize they’re trying to use your app from a cell phone with poor service. So you have the genius idea to add optimistic updates in JS. Now you have all the problems from the article since you need to update all the components everywhere on screen that share state.

All you need is a client-side cache.

How do changes to that cache get displayed? Your cache emits events that each UI element has to listen to? Congrats you’re using redux!

(It would perhaps be more accurate to say that React folks had to reinvent these patterns, but the problems were definitely present in the postback era)

Re: The new wave of React state management

#27
I'm pretty sad this is the point we are at with React frontend development, the library is becoming much larger than it's original scope and it's getting bloated while not solving the essential problems that happen. In my opinion the best solution we have right now for frontend JS development is to not use JS or JSX at all and instead use a DSL such as Svelte, this way the compiler abstracts all complication and there is no application bundle size bloat. Obviously we have Preact (which solves react-dom bloat), MobX (which solves state management), etc. which are all great tools but the problem is that every tech stack is different and the more the core technology can do without getting more bloated the easier it is to introduce new developers to a codebase and keep up with changes.

Re: The new wave of React state management

#28
post #22
post #4

The "state management problem" appears to be an invention of React. This didn't use to be a problem with MVC. The state lives on the server. When state changes it should be persisted on the server immediately (in case the user unexpectedly closes the browser). On the client all you need is a cache. With MVC, each page is more or less independent. Each page gets the data it needs from the server (through a client-side…

Your causation is reversed. People demanded more interactive web apps, which led to more stateful UI, which led to React. In the case of Facebook, the motivating app was Ads Manager — an enormous, highly interactive single page app for advertisers. You couldn’t build something like it with HTML + server endpoints; in the pre-web days, apps with this kind of complexity would be desktop apps. Google Docs, Google Sheets…

> You can’t represent that state on the server without making the UI unusably slow.

And that's why you use a client-side cache.

Re: The new wave of React state management

#29
post #4

The "state management problem" appears to be an invention of React. This didn't use to be a problem with MVC. The state lives on the server. When state changes it should be persisted on the server immediately (in case the user unexpectedly closes the browser). On the client all you need is a cache. With MVC, each page is more or less independent. Each page gets the data it needs from the server (through a client-side…

React wasn't the first complex frontend framework, arguably people were having these state management problems ever since people started doing more stuff like jQuery UI. It's not tied to SPAs either, you can have state management problems for a single URL as long as it has any form of state change (like opening a modal).

Re: The new wave of React state management

#30
post #2

Mobx solved all of the state problems properly a long time ago.

Agreed! I'm surprised at the comprehensive work going into researching the history of state management in this article while completely missing MobX. What problem does MobX not already solve?

came here to say the same thing.
Post reply on HN