I&#x27;ve also observed this similarity. The msg is like the actionType, the wParam and&#x2F;or lParam are like the polymorphic objects that you pass with your action.<p>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&#x27;s handle (hwnd). This doesn&#x27;t make sense in Flux, since it&#x27;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.<p>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.<p>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.<p>Minor nit: stores are just caches with observers. I&#x27;m not sure why they weren&#x27;t just called caches.