4 ms·

MobX does not get enough love and has been around for a while https://mobx.js.org/README.html https://mobx.js.org/README.html

fyp 7y ago
I found the philosophy communicated by mobx-state-tree to be a lot clearer than redux (particularly stuff around patches, snapshots and async flows): https://mobx-state-tree.js.org/intro/philosophy https://mobx-state-tree.js.org/intro/philosophy
sansnomme 7y ago
Check out Svelte. Essentially reactivity baked into the compiler so you don't have to use observables everywhere.
- leetrout 7y ago
  Second time it’s been mentioned in as many days. Are you actively using it?
  - sansnomme 7y ago
    Yes it is pretty straightforward though the project is still growing and suffering from the usual growing pains. Think docs that has plenty of room for improvement, insufficient example projects and components. On the up side the team responds quickly, the concepts are ridiculously simple compared to Redux and there's a burgeoning community around it. E.g. https://sveltematerialui.com/ https://sveltematerialui.com/ The Next.js equivalent for SSR is Sapper: https://sapper.svelte.dev/ https://sapper.svelte.dev/ Note the creator of Svelte is the same guy who created the Rollup bundler so pretty much everything comes with dual configs for both Rollup and Webpack.
- Kiro 7y ago
  One of the main reasons I'm using Redux is because of the global store. If I understand the docs correctly this is how you do it in Svelte: https://svelte.dev/examples#writable-stores https://svelte.dev/examples#writable-stores What's up with that? A strange semi-singleton where you need to use writable(0)? Also strange that subscribe return unsubscribe. Doesn't seem very intuitive.
hnbreak 7y ago
IDK, it's good to have competition but I could never get warm with mobx, undo is not baked it, more magic, similar learn curve but less real understanding at the end. Then, the biggest bummer, you have also mobx state tree which is too much fragmentation within mobx.
Drdrdrq 7y ago
MobX doesn't get enough hate either. Inexperienced devs will put everything in the global state and end up with a soup. And, as opposed to Redux, it is _magic_ - I would have trouble rewriting it from the docs, would you be able to do it? Note that it also changes the way React render method works. All in all - no thank you.
- leetrout 7y ago
  Sloppy developers are sloppy in redux as well. Vuex has a nice pattern with plugins and modules. Mobx stands on its own outside of react. I understand many people don’t consider redux outside of react and don’t talk about one without the other. As other comments mentions the mobx state tree is more a drop in replacement for redux. I am unfamiliar with the render method changes you reference- do you have more info or a link?
  - Drdrdrq 7y ago
    > Sloppy developers are sloppy in redux as well. Agreed. But the mess they make in MobX is in my experience much more difficult to clean up. What I meant with render method changes is that mobx tracks access to state during a call to render (which means that anything that might influence rendering, must be accessed inside render). It seems like it's not a big deal, but it can lead to surprising bugs if one is not careful. Redux otoh uses props to pass data to render, which is much more explicit and allows regular react dev tools to be used. I might have some details wrong - I met MobX a year ago with two legacy apps and it was a hell to maintain. Still is actually, I'm just not that involved in these projects anymore. It's magic, and not in a good way. For new projects we use Redux Toolkit, which strikes a nice balance between verbosity and being explicit.
- _bxg1 7y ago
  > Inexperienced devs will put everything in the global state and end up with a soup. And Redux is just one big global state > it is _magic_ - I would have trouble rewriting it from the docs, would you be able to do it? I accidentally wrote a (bad) version of MobX's core mechanism before I learned about it. At its heart it just uses object Proxies to intercept getters and setters; the former to find out where something is used, the latter to find out when it changes. It can feel a bit magical sometimes, but the magic isn't hard to understand, almost always just works, and when it doesn't do what you want it usually causes a performance impact, not breakage. > Note that it also changes the way React render method works. I don't know what you mean. Aside from "tracking" which observables get accessed within it, all it does is decide when to trigger updates.
wetpaws 7y ago
Friends don't let friends use observables
- wbercx 7y ago
  Could you elaborate on this?
  - wetpaws 7y ago
    I saw enough large scale knockout projects to see how quickly observable based code fold down into a disjoined incoherent mess. At some point it's virtually impossible to debug or support it. I'm not sure who downvotes me, people who successfully used them in production or who dont and don't know they are in for the ride, but for me this is an insanity and I won't touch mobx even with a six feet pole.
    - Kiro 7y ago
      What do you use instead?
    - _bxg1 7y ago
      I've been using MobX on a quite large and complex React app for a few years now and I have no regrets. The key, as in all programming, is to make your (observable) state as small as possible. You shouldn't have observables that are derived from other observables; you should have computed values. You should use reactions sparingly and almost never use them to mutate other observables. Etc. MobX lets you treat state as state and then get all the benefits of memoization and reactivity that you want, for free. It only gets hairy when your state itself gets needlessly hairy.
    - leetrout 7y ago
      I was not a fan of knockout AT ALL. But here we are. People would get too clever and abstract way too much. I don’t see the same with Vuex and MobX but I can understand why you feel that way based on this reply. The concept of having a centralized state / store with complex apps is impossible to ignore IMO (even if you just have plain objects holding them). At that point sprinkling in a pattern to standardize access isn’t that much overhead.
_bxg1 7y ago
I love love love MobX. It lets me design my data flow however I want - local or global, functional or imperative, and everything in-between - while basically forgetting about pub/sub entirely until it comes time to do spot optimizations. It's removed an entire layer of mental overhead, without contorting the entire app into a complex and boilerplate-y new paradigm.

fyp 7y ago

I found the philosophy communicated by mobx-state-tree to be a lot clearer than redux (particularly stuff around patches, snapshots and async flows): https://mobx-state-tree.js.org/intro/philosophy https://mobx-state-tree.js.org/intro/philosophy

sansnomme 7y ago

Check out Svelte. Essentially reactivity baked into the compiler so you don't have to use observables everywhere.

leetrout 7y ago
Second time it’s been mentioned in as many days. Are you actively using it?
- sansnomme 7y ago
  Yes it is pretty straightforward though the project is still growing and suffering from the usual growing pains. Think docs that has plenty of room for improvement, insufficient example projects and components. On the up side the team responds quickly, the concepts are ridiculously simple compared to Redux and there's a burgeoning community around it. E.g. https://sveltematerialui.com/ https://sveltematerialui.com/ The Next.js equivalent for SSR is Sapper: https://sapper.svelte.dev/ https://sapper.svelte.dev/ Note the creator of Svelte is the same guy who created the Rollup bundler so pretty much everything comes with dual configs for both Rollup and Webpack.
Kiro 7y ago
One of the main reasons I'm using Redux is because of the global store. If I understand the docs correctly this is how you do it in Svelte: https://svelte.dev/examples#writable-stores https://svelte.dev/examples#writable-stores What's up with that? A strange semi-singleton where you need to use writable(0)? Also strange that subscribe return unsubscribe. Doesn't seem very intuitive.

hnbreak 7y ago

IDK, it's good to have competition but I could never get warm with mobx, undo is not baked it, more magic, similar learn curve but less real understanding at the end. Then, the biggest bummer, you have also mobx state tree which is too much fragmentation within mobx.

Drdrdrq 7y ago

MobX doesn't get enough hate either. Inexperienced devs will put everything in the global state and end up with a soup. And, as opposed to Redux, it is _magic_ - I would have trouble rewriting it from the docs, would you be able to do it? Note that it also changes the way React render method works. All in all - no thank you.

leetrout 7y ago
Sloppy developers are sloppy in redux as well. Vuex has a nice pattern with plugins and modules. Mobx stands on its own outside of react. I understand many people don’t consider redux outside of react and don’t talk about one without the other. As other comments mentions the mobx state tree is more a drop in replacement for redux. I am unfamiliar with the render method changes you reference- do you have more info or a link?
- Drdrdrq 7y ago
  > Sloppy developers are sloppy in redux as well. Agreed. But the mess they make in MobX is in my experience much more difficult to clean up. What I meant with render method changes is that mobx tracks access to state during a call to render (which means that anything that might influence rendering, must be accessed inside render). It seems like it's not a big deal, but it can lead to surprising bugs if one is not careful. Redux otoh uses props to pass data to render, which is much more explicit and allows regular react dev tools to be used. I might have some details wrong - I met MobX a year ago with two legacy apps and it was a hell to maintain. Still is actually, I'm just not that involved in these projects anymore. It's magic, and not in a good way. For new projects we use Redux Toolkit, which strikes a nice balance between verbosity and being explicit.
_bxg1 7y ago
> Inexperienced devs will put everything in the global state and end up with a soup. And Redux is just one big global state > it is _magic_ - I would have trouble rewriting it from the docs, would you be able to do it? I accidentally wrote a (bad) version of MobX's core mechanism before I learned about it. At its heart it just uses object Proxies to intercept getters and setters; the former to find out where something is used, the latter to find out when it changes. It can feel a bit magical sometimes, but the magic isn't hard to understand, almost always just works, and when it doesn't do what you want it usually causes a performance impact, not breakage. > Note that it also changes the way React render method works. I don't know what you mean. Aside from "tracking" which observables get accessed within it, all it does is decide when to trigger updates.

wetpaws 7y ago

Friends don't let friends use observables

wbercx 7y ago
Could you elaborate on this?
- wetpaws 7y ago
  I saw enough large scale knockout projects to see how quickly observable based code fold down into a disjoined incoherent mess. At some point it's virtually impossible to debug or support it. I'm not sure who downvotes me, people who successfully used them in production or who dont and don't know they are in for the ride, but for me this is an insanity and I won't touch mobx even with a six feet pole.
  - Kiro 7y ago
    What do you use instead?
  - _bxg1 7y ago
    I've been using MobX on a quite large and complex React app for a few years now and I have no regrets. The key, as in all programming, is to make your (observable) state as small as possible. You shouldn't have observables that are derived from other observables; you should have computed values. You should use reactions sparingly and almost never use them to mutate other observables. Etc. MobX lets you treat state as state and then get all the benefits of memoization and reactivity that you want, for free. It only gets hairy when your state itself gets needlessly hairy.
  - leetrout 7y ago
    I was not a fan of knockout AT ALL. But here we are. People would get too clever and abstract way too much. I don’t see the same with Vuex and MobX but I can understand why you feel that way based on this reply. The concept of having a centralized state / store with complex apps is impossible to ignore IMO (even if you just have plain objects holding them). At that point sprinkling in a pattern to standardize access isn’t that much overhead.

_bxg1 7y ago

I love love love MobX. It lets me design my data flow however I want - local or global, functional or imperative, and everything in-between - while basically forgetting about pub/sub entirely until it comes time to do spot optimizations. It's removed an entire layer of mental overhead, without contorting the entire app into a complex and boilerplate-y new paradigm.