[picardo]

Nice documentation. But I don't see anything groundbreaking here. The whole rationale for Flux is to unidirectional state flow, and it does that quite well. A lot of library creators have focused on the tiny quibbles with "ease of use" around stores and constants –– "state management" is a good euphemism for this need –– but that's not really a bottleneck for me. I can manage my constants manually with Flux, and add listeners myself. If I need to indicate a dependency between to stores, I can use a waitFor in the switch/case block. It's that simple. Why should I learn a bunch of abstractions that make only an incremental difference?

My only pet peeve with Flux is that it does not let me dispatch from within an ongoing dispatch, which is not a huge deal yet because you can just defer the callback to the next event loop, but it's not allowing me to pipeline actions as I thought it should. I have to wait for the stack to empty out before I can dispatch a new action, which sucks. Also, there is no indication as to when a dispatch is over, so I am deferring dispatches by instinct –– or wrapping them in a promise might be the same thing.

[jfhollingworth]

Hey, author here. This is a repeat of my answer below but it's right down the bottom so might be missed:

I found that no other Flux implementation really helped with fetching data in a Fluxy way. There tended to be a lot of boiler plate code for binding stores to components. Furthermore, there was a lack of tooling for debugging. Marty helps combat these issues by introducing a number of new things:

- Fetch API for fetching data asynchronously without callbacks http://martyjs.org/guides/stores/fetching-data.html - State Mixins for binding stores to views http://martyjs.org/api/state-mixin/ - State sources for syncing state from heterogeneous sources http://martyjs.org/guides/state-sources/index.html - Chrome Developer extension (beta) for visualising the data flow and state of stores http://martyjs.org/devtools/

[picardo]

You're right about the boilerplate. I use a wrapper around React.createClass to take care of that. Kinda similar to Marty.createStateMixin, but it's just a component factory.

The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store. It's a nice to have, but not filling a need for me.

[catshirt]

> The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store.

by that logic, you don't need a debugger with breakpoints and stack traces either.

i mean... you could use a spoon for driving nails into wood instead of a hammer, too.

[picardo]

I could also use a jackhammer, but that's not what jackhammers are for.

[eric_bullington]

The Flux pattern contains too much boilerplate and indirection for small or quick one-of web apps. If Marty helps to abstract some of that out, it's more than welcome to me.

Frankly, for small apps, I think you can get 90% of the benefit of Flux by using the pubsub solution of your choice and taking care about only subscribing from top-level components and passing state change down to their children. Immutable cursors are also a nice solution for small apps.

I get that for large teams working on massive code bases, and possibly even for smaller apps, Flux is a big plus. But I'm glad that projects like Marty are working on abstracting out all the boilerplate. Less code for me to worry about.

[fisherwebdev]

I find that small apps tend to turn into big apps over time, and Flux lets us build with the confidence that, as new features are developed, our apps won't have to be deeply rewritten. New, unexpected features tend to fall into place with Flux, with a minimum of effort. I have seen this time and time again in working with Flux.