[wetpaws]

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.

[_bxg1]

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.

[canacrypto]

I've been burned by observables in a large scale knockout project too. Definitely left my weary of observables for UI development in general.

[leetrout]

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.

[Kiro]

What do you use instead?