Mobx isn't ugly at all. Are you using decorators? You should.

Example:

    import { observable } from "mobx";
    export default class TodoStore {
      @observable todos = [];
      constructor(props) {}
    }

    // Elsewhere in a different file, now you just use it.
    import TodoStore    from './stores/todos_store.js';
    import { observer } from 'mobx-react';
    @observer
    export default class Todos extends Component {
      constructor(props) {
        store = new TodoStore()
      }

      addTodo = (todo) => {
        store.todos.push({ id: 1, text: "Get Milk" });
      }

      render() {
        return (
          // Just iterate over `store.todos`
        )
      }
    }

As you can see you just use the variables and get stuff for free out of the box with no plumbing code except `@observable` and @observer`. What's not to love?

Some questions already arise from that example:

- How do two separate components access the one store, singletons?

- If two components observe the same store but render different attributes of it are they both updated when the store is updated?

- Are you limited to modifying your store only in your component?

> How do two separate components access the one store, singletons?

You can use <Provider> and @inject to put a store onto the component tree and pull it off whenever you need it. It's just a quick wrapper around the React context API.

> If two components observe the same store but render different attributes of it are they both updated when the store is updated?

Yes, this is just how Mobx works. Observations are set up implicitly. You can observe any @observable value or @computed function just by referencing it within an @observer.

> Are you limited to modifying your store only in your component?

Nope, this works with just plain JavaScript. The main library doesn't offer any React-specific bindings (like Redux), so it can be used with anything.

> What's not to love?

For me? Basically all of that. Also now that code is highly dependent on the framework and tightly coupled.

Observables have their place for sure, I like them as a concept actually, but for me MobX is encoding an anti-pattern I try to avoid.

Be careful you don't become an architecture astronaut though. At some point you have to stop working on plumbing and actually solve the business need.

https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

Indeed, a good point to be aware of generally (though I would say we as a group go too far the other direction most times).

But the issue here with that is that I can solve the business needs in React+Redux trivially without running into the architectural problems I mentioned in MobX.

So why on earth would I chose the inferior option?

So much FUD

I swear, there are some users on HN (like yourself) that think FUD is some kind of magic pixie dust to invalidate someones statement. I thought we grew out of that in the early 2000s.