8 ms·

I'd love to hear more from people that expressed certain viewpoints - specifically those who used a library but wouldn't use it again... Specifically mobx :) I

• easong 10y ago
  I love mobx (definitely not one of the 58), but I would use redux on large apps (maybe, more than 15 pages?), especially if you don't care too much about performance. Redux has better debugging, forces more structure to the code, has a immutable data story, and there are more resources on the net if you need to bring developers up to speed. There are some configuration options for MobX that force the user to be more organized, but redux still feels more structured. That being said, MobX is absolutely my go-to state management library now - it's probably the easiest free FPS you'll find anywhere, it's ridiculously easy to write, and it results in fewer LOC.
  • smac8 10y ago
    Second that, MobX has been a total game changer for me. Used redux and really like the philosophy of it, but overall feel mobx is much easier to use while accomplishing just as much, and the simplicity and lack of boilerplate actually makes reasoning about state, testing, etc much easier than redux. I disagree about large apps (switched to mobx on a large app now), but I can roughly see what you are saying. Still, I think MobX is great on large apps
  • acemarke 10y ago
    Out of curiosity, why do you say "don't care much about performance"? Redux can be _extremely_ performant, although it does take a bit of thinking about how your data is organized. I've got several articles discussing Redux performance [0] in my React/Redux links list [1]. In particular, check out Dan Abramov's PR to a MobX/Redux benchmark [2], and the article "High Performance Redux" [3]. Finally, the upcoming React-Redux v5 release shows noticeable improvements in a variety of scenarios [4]. Any specific issues with Redux performance that you've noticed? [0]: https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [1]: https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#redux-performance https://github.com/markerikson/react-redux-links/blob/master... [2]: https://github.com/mweststrate/redux-todomvc/pull/1 https://github.com/mweststrate/redux-todomvc/pull/1 [3]: http://somebody32.github.io/high-performance-redux/ http://somebody32.github.io/high-performance-redux/ [4]: https://github.com/reactjs/react-redux/pull/416 https://github.com/reactjs/react-redux/pull/416
• saosebastiao 10y ago
  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
• cloverich 10y ago
  Yeah just to add-on to what other people are saying in replies, another happy mobx user. If I could guess at a complaint, I've worked on Ember projects (which have some similar observer / mutable capabilities) and have seen how "clever" observer / mutable-state code can turn out (overly complex). Which is to say -- it gives you some really awesome capabilities but no pre-set architecture for setting up your data modeling layer. At any rate, I really expect this library to take-off in the next year or two, and love introducing it to people who have not heard of it (normal response: "What? Whoa"). If you already have a lot of React experience, I think their 25-line timer example is a great place to see what it can do for you: https://jsfiddle.net/mweststrate/wgbe4guu/ https://jsfiddle.net/mweststrate/wgbe4guu/