Mobx solved all of the state problems properly a long time ago.
What problem does MobX not already solve?
21–30 of 310 posts
Mobx solved all of the state problems properly a long time ago.
What problem does MobX not already solve?
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…
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.).
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…
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
After reading the "Grug Developer" article recently, I've been thinking of frontend development as "The Plane of Eternal Complexity Demons".
Of course it’s best to avoid UI programming entirely, but in many domains it’s necessary.
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?
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.
(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)
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…
And that's why you use a client-side cache.
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…
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?