[sepeth]

Is there a way to get rid of flux boilerplate? I don't want to write three different files (a file with actions, another file with constants, and the actual store). For example, I can achieve the same effect with just a simple array and some functions to modify it. I guess I know what the benefit of embracing flux is, but it still looks too much, and I am mostly lazy.

[jonpaine]

Sure - just use what you want. Outside of the dispatcher, flux is mostly a design specification for clientside information flow. Actions, stores, etc aren't native to flux - they're just approaches for accomplishing the desired information flow. Check out the examples closer - they aren't react classes.

That said, my personal opinion: the deeper you get into a big project the more you'll see the incredible value of the approach. The breakeven between the overhead of learning the approach vs the productivity (and performance improvement) of using it comes pretty early on, in my opinion.

With a lot of software, the more I get deeply into a project the more I feel I'm battling the artificial constraints of the tools I'm using. Flux is exactly the opposite. The deeper I get in, the more I feel it's working for me (and I'm not even using their dispatcher - since I had written my own initially before flux came out, so I can't speak directly to their dispatcher, just the Flux design styling within a React project).

[veeti]

Reflux is a Flux library without the dispatcher boilerplate.

[cnp]

+1 On Reflux. They have an awesome new async api now, too.

[nwienert]

Fynx reduces it even more if you use immutable data. You only worry about the actions.

[igvadaimon]

I am currently using alt: https://github.com/goatslacker/alt

It's very small and removes boilerplate, but still isomorphic.

[mcx]

I'm also using alt and enjoying it. I like that it sticks close to the FB implementation of Flux but there is less boilerplate along with utilities such as bootstrap, snapshot, etc.

[jbhatab]

yup, also liking alt.

[benihana]

You just articulated all the issues I have with these frameworks (Backbone is another one that comes to mind) - the boilerplate code violates the hell out of YAGNI, which for me is a core principle of my development style.

You end up building a ton of boilerplate code that is capable of handling anything your system evolves into, but most of it is wasted because each part of the system typically only uses a small subset of functionality of the framework. So you're left with a bunch of big crufty systems laying around. When I want to be the most lightweight and agile and capable of changing my direction is at the beginning of a project when I'm still learning how the system will work. These frameworks make it really tough (at least for me) to do that so I end up not using them.