12 ms·

After using Mobx for a few weeks, I've come to question why anybody would use anything else. It is the only software I've ever used that was created for a dynam

After using Mobx for a few weeks, I've come to question why anybody would use anything else. It is the only software I've ever used that was created for a dynamic language that has me trying to re-implement in my favored strong/static typed languages. Now I just point and laugh at anybody trying to make sense of their Redux global state atom with a bajillion reducers. So far, I've only found one common objection to it: that it embraces mutable state. Well duh...UIs are state machines. They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state. And because of this, my opinion of this objection is that it is of a religious nature. You can ignore this particular objection with no risk at all.

arxpoetica 10y ago
I'm really interested in what you're saying about UIs as state machines. Do you have any articles/references to back this up? Genuine curiousity here.
- kuon 10y ago
  I second that. My experience shows it is a state machine, but I have not see any formal study of it.
  - anewhnaccount 10y ago
    Well everything that happens in a real computer is an FSM. There's a finite amount of memory and therefore a finite number of states.
    - DonHopkins 10y ago
      That's playing fast and loose with the literal every-day definition of the words "finite", "state" and "machine". There is actually something in computer science with a precise mathematical definition called a "finite state machine," [1] that is not simply any machine that has a finite number of states. When you use that term, you're not just talking about what it can do, but also what it can't do, because "finite state machine" implies that it's just a finite state machine, not a pushdown automata, and not a Turing machine. With a Turing machine, you can implement a finite state machine or a pushdown automata, but Turing machines and pushdown automata are more than just finite state machines. That said, user interfaces typically use lots of finite state machines at different levels (hierarchical, and unrelated), but they also require more powerful machines like pushdown automata and Turing machines (for validating email addresses, for examples). If all you had to program user interfaces were finite state machines, but no Turing machines, you would be a very frustrated programmer, and your users would be unhappy to have such a brittle inflexible user interface. [1] https://en.wikipedia.org/wiki/Finite-state_machine https://en.wikipedia.org/wiki/Finite-state_machine
      - anewhnaccount 10y ago
        It's not playing fast and loose at all - at least not with the precise mathematical definition (perhaps it is playing fast and loose with the "literal every-day" definition which might mean a state machine with few enough states to fit on a whiteboard). A push down automata is defined as having infinite stack and a Turing machine is defined as having infinite tape. A finite stack push down automata permits an equivalent (much larger) finite state machine. A finite tape Turing machine also permits an equivalent (much much larger) finite state machine. Leslie Lamport makes the same observation on page 4 here: http://research.microsoft.com/en-us/um/people/lamport/pubs/state-machine.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/s... The comment I replied to was "My experience shows it is a state machine, but I have not see any formal study of it." - I was simply replying "of course it's a state machine". Lots of situations in GUIs can be modelled as quite compact state machines - but it depends on the level you model it at. If you need to model the state of a text box then your state machine will grow very large since you need a new state for every possible input string. Given modelling simplifications where we abstract away some parts with large state spaces by collapsing states, there are very few pieces of software which don't benefit from being modelled with state machines. Personally I would be a very frustrated programmer and if I had to program user interfaces with Turing machines since writing a transition table would feel awfully low level and since the Turing machine model doesn't have any facilities for user interaction I'm not sure any users would be terribly happy with the result (so I'm not quite sure what you're trying to say here).
- rifung 10y ago
  The person you're replying to didn't specify whether UIs are represented as state machines which are finite or infinite, but I'll assume finite since infinite automata are more powerful than Turing machines so they presumably can represent something which is made by a computer. UIs in general can not be represented by finite state machines. An example is a page with a button which when pressed adds something to the page. Since there are an infinite number of things that could potentially be added, this can't be represented by a finite number of states. On the other hand, I think many UIs could be represented by finite state machines, although perhaps sometimes only roughly. You can start by trying to specify that each instance of a specific page a user can see is presented by a state, and any interaction with the user that leads to a different rendering of the same or a new page is a transition. However, this fails to account for things where a user can do something which doesn't change the current page but might change a later page. You can account for this by having multiple states which show the same exact UI but have different transitions to future pages. Of course, it isn't just the user who can interact with your system to produce a different UI for other people, so you'd have to model those transitions and states too.. I'm not a front end developer so I don't know how many UIs can actually be modeled this way, but I can see how it might be a useful way to think about things, even if it isn't necessarily always correct.
  - saosebastiao 10y ago
    I didn't specify finite or infinite, and you're right that FSMs alone aren't sufficient to describe all UIs. But they are sufficient to describe nearly all interactive UIs. Your infinite button example still has a finite state, but it's not modeled explicitly, and would probably be a good idea, for very practical reasons, to do so. If it really goes on forever, you'll eventually run out of memory, whether that memory is managed by the rendering engine (appending dom elements?) or by the language runtime. > However, this fails to account for things where a user can do something which doesn't change the current page but might change a later page. A Hierarchical State Machine model covers this scenario quite nicely...which is exactly what React is.
    - rifung 10y ago
      Interesting. I hadn't heard of hierarchical state machines. Thanks for the reply. If you don't consider the infinite button example, then what other kind of UI can not be described by a FSM?
- saosebastiao 10y ago
  If you have an interactive UI, you have a state. A button is either pressed or it is not pressed, active or disabled or hidden. A text form has a text value. Your layout has state (position, color, etc.). If your UI is interactive, you have events and actions that mutate that state. A keyboard event modifies the state of your text form field. A button press signals an action. Etc. A state machine is `State0 + Event -> Action + State1`. Since your UI's entire functionality can be described by the state it is in combined by the Events and resulting Actions and changes in States, your UI is a state machine. This describes the superset of all UIs. Non-interactive UIs can still be described by this, although the benefits are slim because the state isn't really mutated without interactivity, so your State0 is always equal to your State1. Note that I'm saying UIs are state machines...not like state machines. They literally are state machines. Whether you model them as such is up to you, but my claim here is that modeling your UIs as state machines has tangible benefits because they are state machines. Funnily enough, there are plenty of articles out there that claim to make stateless UIs. These claims are false...any critical look at the model shows that the state exists, but either is modeled implicitly (keeping state in the DOM and outside of javascript, or within a rendered object, or within a closure attached to an observer somewhere, etc.), or explicitly moved somewhere else. There might be some merits to the latter model (as well as some drawbacks), but the former model is just delusion...a perfectly leaky abstraction where you have state, but have lost your ability to work with it.
glenjamin 10y ago
I'm unconvinced by this argument. State machines don't let you change things whenever you feel like it. There are a set number of states and a bunch of predefined transitions between them. That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints. Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach.
- saosebastiao 10y ago
  > That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints. Redux doesn't force you to apply constraints any more than Mobx does. In fact, it's even less structured than Mobx...any component anywhere can emit any event that modifies any state. With mobx, you can only modify state that you have an actual reference to. > Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach. I agree that semantically immutable data structures are easier to comprehend and work with. But you still have to mutate state, or you don't have a UI. With immutable structures, you copy->modify->replace...with mutable structures, you mutate in place. You can't avoid mutating state with UI programming, so embracing a model that embraces intelligent manipulation of mutable state isn't an indictment, it's a tangible benefit.
- aidos 10y ago
  I made a poc with Redux and I felt that a) the boilerplate obscured my code b) the async story was pretty confusing and c) managing my derived / calculated properties was really hard. One thing I've discovered is that a lot of the logic is derived data in the form of pure functions. A huge amount of my codebase seems to be about managing the derived state that trigger from a core bit of state changing. Really there's actually a much smaller core set of data, and then various aggregations on top of that (with the component view tree being the final representation). I initially played with MobX a while back and had the worry that you could end up with state changes triggering off all over the place, but I don't think it needs to be like that. There's no reason you can't have core state, layers of calculated properties and a view. Having said that, it's early days, which is why I'm looking to hear real stories of where MobX hasn't worked. My approach when evaluating technology is to try to find ways in which it works poorly so that if I do pick it up I'll have an idea of the limitations (and can try to work around them). MobX does also have "strict mode" where you have to declare the transition points. I know that's not really the same as the reducer model, but it does force people to think about when state will be updated.
indexerror 10y ago
> They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state. Can you give an example of this? I have worked on fairly complex Redux applications but have never ever mutated states and it has been just fine. In fact, I use ImmutableJS to keep my apps' states. State machines without immutability in a large application sounds like a joke to me, sorry.
- saosebastiao 10y ago
  If you haven't mutated states, you don't have an interactive UI. With immutable data structures holding your state, you mutate it by re-assigning variables. This is exactly what Redux does. In fact, the rendering benefits of immutable data structures comes from the fact that you can perform equality comparisons by reference safely, and ref comparisons are faster. Any time you re-assign a variable, you change that variable's reference, and it is no longer necessary to deep check the reference's value to know that it changed.
  - somlor 10y ago
    > If you haven't mutated states, you don't have an interactive UI. React allows you to treat DOM mutation as an expression of current app state. This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). I'm befuddled where you're getting the impression that immutable data structures themselves require mutation.
    - saosebastiao 10y ago
      > React allows you to treat DOM mutation as an expression of current app state. Current app state. As in not past state. Not future state. There would be no need for the distinction if the state wasn't mutated. > This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). You are confusing the mutability of a data structure with the mutability of state. You can model mutable state using immutable data structures, but it's mutable state regardless. In fact, that is exactly what the Redux/ImmutableJS model is. If the state of your "immutable" react app were really immutable, you would have a webpage, not an app.
spion 10y ago
The right way to get rid of mutable state is to replace it with a stream abstraction, which declaratively models how the state changes in response to events. That would be cyclejs: http://cycle.js.org/ http://cycle.js.org/ Too bad that this model doesn't work well with React. React models the UI as a (mostly pure) function from props/state input to DOM output, however in reality the UI is a stream containing both DOM states and input events. The minimal modification would be to select the input events that a component would like to expose in its event stream, in a similar manner to Elm: https://guide.elm-lang.org/reuse/checkboxes.html https://guide.elm-lang.org/reuse/checkboxes.html
- aidos 10y ago
  Why do you say that's the right way? Is there something intrinsically better about having the state modelled as a stream of changes? Is that really getting rid of mutable state? [EventA, EventB] is a mutation of [EventA], sure it's a WAL style, but the combined final state is a mutated version of the original state. Presumably the concrete state model (like MobX) is a realisation of the event stream at a moment in time. As far as the user is concerned, the only moment in time that really matters is now.
  - nine_k 10y ago
    Mutable state is fundamentally harder to reason about. You get aliasing bugs, stale cached values, etc. With immutable data in an append-only stream this is simply impossible.
    - aidos 10y ago
      I've done plenty of work with immutable data, and I tend to code in a way that minimizes the amount of state I have to manage. I guess that's what I was saying about mobx though - I can have a much smaller set of core data and then pure functions for the layers of derived data. And it's a) easy to reason about and b) super performant at managing the calculations. Aliasing bugs don't really apply in JS, unless there's some variation of the term? Stale caching is also not an issue with calculated derived data.

arxpoetica 10y ago

I'm really interested in what you're saying about UIs as state machines. Do you have any articles/references to back this up? Genuine curiousity here.

kuon 10y ago
I second that. My experience shows it is a state machine, but I have not see any formal study of it.
- anewhnaccount 10y ago
  Well everything that happens in a real computer is an FSM. There's a finite amount of memory and therefore a finite number of states.
  - DonHopkins 10y ago
    That's playing fast and loose with the literal every-day definition of the words "finite", "state" and "machine". There is actually something in computer science with a precise mathematical definition called a "finite state machine," [1] that is not simply any machine that has a finite number of states. When you use that term, you're not just talking about what it can do, but also what it can't do, because "finite state machine" implies that it's just a finite state machine, not a pushdown automata, and not a Turing machine. With a Turing machine, you can implement a finite state machine or a pushdown automata, but Turing machines and pushdown automata are more than just finite state machines. That said, user interfaces typically use lots of finite state machines at different levels (hierarchical, and unrelated), but they also require more powerful machines like pushdown automata and Turing machines (for validating email addresses, for examples). If all you had to program user interfaces were finite state machines, but no Turing machines, you would be a very frustrated programmer, and your users would be unhappy to have such a brittle inflexible user interface. [1] https://en.wikipedia.org/wiki/Finite-state_machine https://en.wikipedia.org/wiki/Finite-state_machine
    - anewhnaccount 10y ago
      It's not playing fast and loose at all - at least not with the precise mathematical definition (perhaps it is playing fast and loose with the "literal every-day" definition which might mean a state machine with few enough states to fit on a whiteboard). A push down automata is defined as having infinite stack and a Turing machine is defined as having infinite tape. A finite stack push down automata permits an equivalent (much larger) finite state machine. A finite tape Turing machine also permits an equivalent (much much larger) finite state machine. Leslie Lamport makes the same observation on page 4 here: http://research.microsoft.com/en-us/um/people/lamport/pubs/state-machine.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/s... The comment I replied to was "My experience shows it is a state machine, but I have not see any formal study of it." - I was simply replying "of course it's a state machine". Lots of situations in GUIs can be modelled as quite compact state machines - but it depends on the level you model it at. If you need to model the state of a text box then your state machine will grow very large since you need a new state for every possible input string. Given modelling simplifications where we abstract away some parts with large state spaces by collapsing states, there are very few pieces of software which don't benefit from being modelled with state machines. Personally I would be a very frustrated programmer and if I had to program user interfaces with Turing machines since writing a transition table would feel awfully low level and since the Turing machine model doesn't have any facilities for user interaction I'm not sure any users would be terribly happy with the result (so I'm not quite sure what you're trying to say here).
rifung 10y ago
The person you're replying to didn't specify whether UIs are represented as state machines which are finite or infinite, but I'll assume finite since infinite automata are more powerful than Turing machines so they presumably can represent something which is made by a computer. UIs in general can not be represented by finite state machines. An example is a page with a button which when pressed adds something to the page. Since there are an infinite number of things that could potentially be added, this can't be represented by a finite number of states. On the other hand, I think many UIs could be represented by finite state machines, although perhaps sometimes only roughly. You can start by trying to specify that each instance of a specific page a user can see is presented by a state, and any interaction with the user that leads to a different rendering of the same or a new page is a transition. However, this fails to account for things where a user can do something which doesn't change the current page but might change a later page. You can account for this by having multiple states which show the same exact UI but have different transitions to future pages. Of course, it isn't just the user who can interact with your system to produce a different UI for other people, so you'd have to model those transitions and states too.. I'm not a front end developer so I don't know how many UIs can actually be modeled this way, but I can see how it might be a useful way to think about things, even if it isn't necessarily always correct.
- saosebastiao 10y ago
  I didn't specify finite or infinite, and you're right that FSMs alone aren't sufficient to describe all UIs. But they are sufficient to describe nearly all interactive UIs. Your infinite button example still has a finite state, but it's not modeled explicitly, and would probably be a good idea, for very practical reasons, to do so. If it really goes on forever, you'll eventually run out of memory, whether that memory is managed by the rendering engine (appending dom elements?) or by the language runtime. > However, this fails to account for things where a user can do something which doesn't change the current page but might change a later page. A Hierarchical State Machine model covers this scenario quite nicely...which is exactly what React is.
  - rifung 10y ago
    Interesting. I hadn't heard of hierarchical state machines. Thanks for the reply. If you don't consider the infinite button example, then what other kind of UI can not be described by a FSM?
saosebastiao 10y ago
If you have an interactive UI, you have a state. A button is either pressed or it is not pressed, active or disabled or hidden. A text form has a text value. Your layout has state (position, color, etc.). If your UI is interactive, you have events and actions that mutate that state. A keyboard event modifies the state of your text form field. A button press signals an action. Etc. A state machine is `State0 + Event -> Action + State1`. Since your UI's entire functionality can be described by the state it is in combined by the Events and resulting Actions and changes in States, your UI is a state machine. This describes the superset of all UIs. Non-interactive UIs can still be described by this, although the benefits are slim because the state isn't really mutated without interactivity, so your State0 is always equal to your State1. Note that I'm saying UIs are state machines...not like state machines. They literally are state machines. Whether you model them as such is up to you, but my claim here is that modeling your UIs as state machines has tangible benefits because they are state machines. Funnily enough, there are plenty of articles out there that claim to make stateless UIs. These claims are false...any critical look at the model shows that the state exists, but either is modeled implicitly (keeping state in the DOM and outside of javascript, or within a rendered object, or within a closure attached to an observer somewhere, etc.), or explicitly moved somewhere else. There might be some merits to the latter model (as well as some drawbacks), but the former model is just delusion...a perfectly leaky abstraction where you have state, but have lost your ability to work with it.

glenjamin 10y ago

I'm unconvinced by this argument. State machines don't let you change things whenever you feel like it. There are a set number of states and a bunch of predefined transitions between them. That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints. Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach.

saosebastiao 10y ago
> That structure is exactly what redux forces you to implement - whereas in MobX it's up to you to apply the same constraints. Redux doesn't force you to apply constraints any more than Mobx does. In fact, it's even less structured than Mobx...any component anywhere can emit any event that modifies any state. With mobx, you can only modify state that you have an actual reference to. > Redux with plain JS objects a a little messy IMO, because there aren't lots of nice & readable ways to transform objects without mutating the previous version. I use it with Immutable JS and am very happy with this approach. I agree that semantically immutable data structures are easier to comprehend and work with. But you still have to mutate state, or you don't have a UI. With immutable structures, you copy->modify->replace...with mutable structures, you mutate in place. You can't avoid mutating state with UI programming, so embracing a model that embraces intelligent manipulation of mutable state isn't an indictment, it's a tangible benefit.
aidos 10y ago
I made a poc with Redux and I felt that a) the boilerplate obscured my code b) the async story was pretty confusing and c) managing my derived / calculated properties was really hard. One thing I've discovered is that a lot of the logic is derived data in the form of pure functions. A huge amount of my codebase seems to be about managing the derived state that trigger from a core bit of state changing. Really there's actually a much smaller core set of data, and then various aggregations on top of that (with the component view tree being the final representation). I initially played with MobX a while back and had the worry that you could end up with state changes triggering off all over the place, but I don't think it needs to be like that. There's no reason you can't have core state, layers of calculated properties and a view. Having said that, it's early days, which is why I'm looking to hear real stories of where MobX hasn't worked. My approach when evaluating technology is to try to find ways in which it works poorly so that if I do pick it up I'll have an idea of the limitations (and can try to work around them). MobX does also have "strict mode" where you have to declare the transition points. I know that's not really the same as the reducer model, but it does force people to think about when state will be updated.

indexerror 10y ago

> They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state. Can you give an example of this? I have worked on fairly complex Redux applications but have never ever mutated states and it has been just fine. In fact, I use ImmutableJS to keep my apps' states. State machines without immutability in a large application sounds like a joke to me, sorry.

saosebastiao 10y ago
If you haven't mutated states, you don't have an interactive UI. With immutable data structures holding your state, you mutate it by re-assigning variables. This is exactly what Redux does. In fact, the rendering benefits of immutable data structures comes from the fact that you can perform equality comparisons by reference safely, and ref comparisons are faster. Any time you re-assign a variable, you change that variable's reference, and it is no longer necessary to deep check the reference's value to know that it changed.
- somlor 10y ago
  > If you haven't mutated states, you don't have an interactive UI. React allows you to treat DOM mutation as an expression of current app state. This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). I'm befuddled where you're getting the impression that immutable data structures themselves require mutation.
  - saosebastiao 10y ago
    > React allows you to treat DOM mutation as an expression of current app state. Current app state. As in not past state. Not future state. There would be no need for the distinction if the state wasn't mutated. > This doesn't mean that your state itself has to mutate. It's entirely possible to structure a React (and/or Redux) app with fully immutable state, copies of which represent change. (Whether copies are done efficiently, e.g. via persistent data structure algorithms, or naively, e.g. via a deep clone, is secondary). You are confusing the mutability of a data structure with the mutability of state. You can model mutable state using immutable data structures, but it's mutable state regardless. In fact, that is exactly what the Redux/ImmutableJS model is. If the state of your "immutable" react app were really immutable, you would have a webpage, not an app.

spion 10y ago

The right way to get rid of mutable state is to replace it with a stream abstraction, which declaratively models how the state changes in response to events. That would be cyclejs: http://cycle.js.org/ http://cycle.js.org/ Too bad that this model doesn't work well with React. React models the UI as a (mostly pure) function from props/state input to DOM output, however in reality the UI is a stream containing both DOM states and input events. The minimal modification would be to select the input events that a component would like to expose in its event stream, in a similar manner to Elm: https://guide.elm-lang.org/reuse/checkboxes.html https://guide.elm-lang.org/reuse/checkboxes.html

aidos 10y ago
Why do you say that's the right way? Is there something intrinsically better about having the state modelled as a stream of changes? Is that really getting rid of mutable state? [EventA, EventB] is a mutation of [EventA], sure it's a WAL style, but the combined final state is a mutated version of the original state. Presumably the concrete state model (like MobX) is a realisation of the event stream at a moment in time. As far as the user is concerned, the only moment in time that really matters is now.
- nine_k 10y ago
  Mutable state is fundamentally harder to reason about. You get aliasing bugs, stale cached values, etc. With immutable data in an append-only stream this is simply impossible.
  - aidos 10y ago
    I've done plenty of work with immutable data, and I tend to code in a way that minimizes the amount of state I have to manage. I guess that's what I was saying about mobx though - I can have a much smaller set of core data and then pure functions for the layers of derived data. And it's a) easy to reason about and b) super performant at managing the calculations. Aliasing bugs don't really apply in JS, unless there's some variation of the term? Stale caching is also not an issue with calculated derived data.