Hacker News new | comments | ask | show | jobs | submit login

I've also observed this similarity. The msg is like the actionType, the wParam and/or lParam are like the polymorphic objects that you pass with your action.

The dispatcher is also not the most efficient model, where every store is registered to listen to every event. This is a bit like multiple windows on an event loop. The difference is that in Windows, messages are almost always targeted to a particular window's handle (hwnd). This doesn't make sense in Flux, since it's more of an observer pattern. The logic of interpreting the meaning of an action is left to each store, which is really just a cache.

The biggest problem I have with Flux relates to this polymophism. I use TypeScript where possible and this is the one place where it always breaks down. I understand the appeal of JS objects but the only way to ensure your Flux based system is stable is to have lots of unit tests around your actions and stores.

Redux is a more straightforward take on caching. I can also use type annotations on the reducers and associated store structure, so this helps ensure structural consistency. It also solves the isomorphism problem of server side rendering because each request can get its own state. There is no out of the box solution for this with Flux, since stores are singletons by default.

Minor nit: stores are just caches with observers. I'm not sure why they weren't just called caches.

I like how Redux is a pretty simple distillation of some flux concepts... In the end, I think it comes down to application scale. The "new" way of mutating models based on OO classes that tend to contain any given amount of logic tends to be much harder to reason with as you add features. More features means a linear to exponential growth in complexity and risk of side effects.

With one-way workflows combined with immutable state, and idempotent components, it's much easier to log/replay/test any given scenario.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact