I'm the author of Fluxy and would be happy to answer any questions here. The big benefits of Fluxy vs other Flux approaches is that
1) Stores are built on top of immutable data structures (via ClojureScript / mori)
2) Server side rendering is baked in (or will be as of 0.4)
Is there a reason why data fetches (e.g. ArticleStore.getByID) don't just return a promise for the return data? I'm guessing the current implementation doesn't return anything, it just emits an event for informing data loaded.
The one plus of the event approach I can think of is that if one component causes new data to load on the client (an article is updated), none of the components that rely on that article will show stale data - that is to say, it's extraordinarily difficult for components looking at the same data to ever be out of sync.
Swagger goes part of the way towards solving this problem, at least for REST apis: http://swagger.wordnik.com/. It's a little annotation heavy for me - I'm guessing you want something that's generated almost entirely from code introspection. And it obviously doesn't work for library code. But I think the UX for an implementer is a great one.
I do love Readme Driven Development (http://tom.preston-werner.com/2010/08/23/readme-driven-devel...), and Github helps here with its per-directory readme displays, but keeping up with these over the duration of a project is obviously a problem, as you note.
Thanks! I've been happy with how simple vows-bdd has made construction of my integration tests.
One big benefit of expresso are its helpers. While it's not difficult to supplement Vows with similar functions, Vows still doesn't have a built-in approach for pre-test bootstrapping.
Jasmine is a great library, especially for anyone coming from the Rspec world. The syntax is incredibly similar to Resp, and when Jasmine is written in CoffeeScript, it's one of the most readable testing libraries I've seen (in any language).
The biggest benefit to Vows is its "everything can be async" nature. This approach makes testing incredibly fast. It's also built in a very modular way that allows for what it calls "batching" - which is really just test metaprogramming. Vows-bdd is just using this capacity for metaprogramming, so it's not too much more than a "mini-DSL" on top of Vows itself.
Vows-bdd is very much inspired by two libraries from Nodejitsu: prenup (a general purpose fluent vocabulary on top of vows) and api-easy (which uses Vows for simple, readable testing of API endpoints). All three of these libraries aren't really doing anything more than pre-wiring Vows tests together. I think it's a reflection of Vows' power that it can be so easily metaprogrammed in this style.
https://github.com/jmreidy/fluxy/tree/master/examples/todomv...