11 ms·

Flux Comparison by Example

145 points by ksmtk 12y ago

bhouston 12y ago
Where do people think up these names: Reflux? http://en.wikipedia.org/wiki/Gastroesophageal_reflux_disease http://en.wikipedia.org/wiki/Gastroesophageal_reflux_disease Why don't we have a library called Melanoma or HIV yet? Actually I am sure we do have libraries with these names somewhere on github.
- ksmtk 12y ago
  haha that's funny! because recently I had reflux disease :)
- deleted 12y ago
  [deleted]
- jvdp 12y ago
  Well, there's Mono...
  - mhd 12y ago
    A language runtime for Unix systems...
- felixvolny 12y ago
  To be fair, the word 'reflux' does have significant meaning outside the context of gastrointestinal disease. I agree some people might have unpleasant associations to the word, but for me this is the first thing that comes to mind: https://en.wikipedia.org/wiki/Reflux https://en.wikipedia.org/wiki/Reflux
- FLUX-YOU 12y ago
  Who knows? Bunch of cheeky bastards with a flux capacitor obsession really.
- pluma 12y ago
  As someone suffering from non-erosive esophageal reflux disease (N.E.R.D., btw), I take no offense from one of the libraries being called Reflux. Drama much?
- gagege 12y ago
  It gives me an uneasy feeling too. It's slightly better than calling a library Vomit.js.
- smackfu 12y ago
  Bigger issue is that utility f.lux.
  - Semiapies 12y ago
    I once saw someone rant for pages and pages about how "flux" was a terrible name for anything because it was an archaic term for diarrhea.
goatslacker 12y ago
This is pretty cool. There have been a ton of flux frameworks floating around lately, glad that there's an app that deals with async data to be able to compare each on their merits.
prottmann 12y ago
Thank you! Yesterday i thought about something similar -> a comparison of different flux implementations with an example (and not with a todo-app). I tried some sample apps in the last weeks with reflux, fluxxor and now marty to see the practical differences.
Narretz 12y ago
Is there a formal spec for a "flux application"? Or what's the common denominator here?
- DougBTX 12y ago
  Closest is probably http://facebook.github.io/flux/docs/overview.html http://facebook.github.io/flux/docs/overview.html
d4n3 12y ago
Anyone tried doing isomorphic (server/client) flux? Most implementations rely on the flux stores being singletons which can't work for multiple requests on the server. The only one that's isomorphic is yahoo's but that one feels terribly verbose.
- ksmtk 12y ago
  I completely agree that Fluxible feels very verbose.. Did you try Reflux.js?
  - amirouche 12y ago
    reflux.js isomorphic support is still in flux https://github.com/spoike/refluxjs/issues/144 https://github.com/spoike/refluxjs/issues/144
  - redonkulus 12y ago
    (fluxible dev here) Which part of Fluxible feels verbose?
    - clarle 12y ago
      For me, it's really the part where you end up having to wrap up all of your actions with `context.executeAction`. It would be cool if there was a nice way that you could wrap an action with a function to generate that boilerplate for you, similar to how Bluebird's `Promise.promisify(myFunction)` generates a Promise-wrapped function for anything following the typical Node callback style.
    - d4n3 12y ago
      - dispatching and listening to actions. you need to pack your action with a magic string and a param object then unpack the params again in every listener. It's easy to forget what the params names are and its hard to see what the function gets as params just from its signature. It would be much nicer to have e.g.: context.actions.myAction('foo', 'bar') And onMyAction: function(foo, bar) - dealing with asynchronous data fetches. The example shows that you should create 3 actions for every async data action: FETCH_STARTED, FETCH_COMPLETE and FETCH_ERROR. How would you deal with cases where you need to fetch multiple data sources then combine them? Seems like the number of actions would quickly explode. Also, how would you deal with dependencies and errors? - the service api: context.service.read('message', {}, {}, function (err, messages) too many optional params, kinda hard to keep track what goes where. I'd prefer something with promises. - I also miss query params support in fluxible router
hleszek 12y ago
So, which one do you prefer and why ?
hoodoof 12y ago
Is there a conclusion, comparison or a point? I'm interested in the outcome but not trawling through the links and stuff.
- ksmtk 12y ago
  there will be summing up article soon, but that's not the main point
  - cies 12y ago
    I would also like your know thoughts on how they compare.
danesparza 12y ago
I'm surprised to discover how useful I found this -- being able to compare roughly 'apples to apples' in an app was very helpful. Thank you for your efforts!
Ronsenshi 12y ago
Great job! It's nice to be able to compare same application elements written in different frameworks - very illustrative. Can't wait for the post with conclusion and thoughts on this.
mukmuk 12y ago
@prottmann alluded to it, but it might be useful to add Marty as well (http://martyjs.org http://martyjs.org) (no affiliation). It's just behind Reflux on the superficial metrics (stars, contributors, npm downloads) so is likely to be on most short-lists. I've had a good experience with Marty so far but remain curious about the others. Reflux worries me a bit because of its minor divergences from the Flux design decisions.
- uxtemple 12y ago
  Same thing here. Marty is proving to be very good and flexible so far while providing a rather succinct implementation overall. +1
- jfhollingworth 12y ago
  I've opened a PR for it but it needs to be merged in https://github.com/voronianski/flux-comparison/pull/5 https://github.com/voronianski/flux-comparison/pull/5
- ksmtk 12y ago
  marty example is added to repo - https://github.com/voronianski/flux-comparison/tree/master/marty https://github.com/voronianski/flux-comparison/tree/master/m...
- mercer 12y ago
  Could you elaborate on your worries? I've used Reflux because it simplified certain things, and I'd love to understand the drawbacks.
namuol 12y ago
It's great to see more example Flux projects using different implementations, but what we really need is just one larger and more sophisticated app example. I've been adapting a React-based app to the Flux architecture for the last week or two. I constantly find myself scratching my head, especially regarding asynchronous operations that need to be reflected in the View. It would be nice for the mock API in these examples to "simulate" a poor network connection in order to see how asynchronous error handling is best handled in each implementation, for instance.
- jfhollingworth 12y ago
  That's why we created https://github.com/jhollingworth/marty-chat-example https://github.com/jhollingworth/marty-chat-example. It's got proper examples of using HTTP & WebSockets
  - namuol 12y ago
    Ha, I actually submitted an issue to this yesterday. It's a good example but misses some really important (i.e. usually-confusing) stuff: error/failure handling and rollbacks.

145 points by ksmtk 12y ago

Where do people think up these names: Reflux? http://en.wikipedia.org/wiki/Gastroesophageal_reflux_disease http://en.wikipedia.org/wiki/Gastroesophageal_reflux_disease Why don't we have a library called Melanoma or HIV yet? Actually I am sure we do have libraries with these names somewhere on github.

ksmtk 12y ago
haha that's funny! because recently I had reflux disease :)
deleted 12y ago
[deleted]
jvdp 12y ago
Well, there's Mono...
- mhd 12y ago
  A language runtime for Unix systems...
felixvolny 12y ago
To be fair, the word 'reflux' does have significant meaning outside the context of gastrointestinal disease. I agree some people might have unpleasant associations to the word, but for me this is the first thing that comes to mind: https://en.wikipedia.org/wiki/Reflux https://en.wikipedia.org/wiki/Reflux
FLUX-YOU 12y ago
Who knows? Bunch of cheeky bastards with a flux capacitor obsession really.
pluma 12y ago
As someone suffering from non-erosive esophageal reflux disease (N.E.R.D., btw), I take no offense from one of the libraries being called Reflux. Drama much?
gagege 12y ago
It gives me an uneasy feeling too. It's slightly better than calling a library Vomit.js.
smackfu 12y ago
Bigger issue is that utility f.lux.
- Semiapies 12y ago
  I once saw someone rant for pages and pages about how "flux" was a terrible name for anything because it was an archaic term for diarrhea.

goatslacker 12y ago

This is pretty cool. There have been a ton of flux frameworks floating around lately, glad that there's an app that deals with async data to be able to compare each on their merits.

prottmann 12y ago

Thank you! Yesterday i thought about something similar -> a comparison of different flux implementations with an example (and not with a todo-app). I tried some sample apps in the last weeks with reflux, fluxxor and now marty to see the practical differences.

Narretz 12y ago

Is there a formal spec for a "flux application"? Or what's the common denominator here?

DougBTX 12y ago
Closest is probably http://facebook.github.io/flux/docs/overview.html http://facebook.github.io/flux/docs/overview.html

d4n3 12y ago

Anyone tried doing isomorphic (server/client) flux? Most implementations rely on the flux stores being singletons which can't work for multiple requests on the server. The only one that's isomorphic is yahoo's but that one feels terribly verbose.

ksmtk 12y ago
I completely agree that Fluxible feels very verbose.. Did you try Reflux.js?
- amirouche 12y ago
  reflux.js isomorphic support is still in flux https://github.com/spoike/refluxjs/issues/144 https://github.com/spoike/refluxjs/issues/144
- redonkulus 12y ago
  (fluxible dev here) Which part of Fluxible feels verbose?
  - clarle 12y ago
    For me, it's really the part where you end up having to wrap up all of your actions with `context.executeAction`. It would be cool if there was a nice way that you could wrap an action with a function to generate that boilerplate for you, similar to how Bluebird's `Promise.promisify(myFunction)` generates a Promise-wrapped function for anything following the typical Node callback style.
  - d4n3 12y ago
    - dispatching and listening to actions. you need to pack your action with a magic string and a param object then unpack the params again in every listener. It's easy to forget what the params names are and its hard to see what the function gets as params just from its signature. It would be much nicer to have e.g.: context.actions.myAction('foo', 'bar') And onMyAction: function(foo, bar) - dealing with asynchronous data fetches. The example shows that you should create 3 actions for every async data action: FETCH_STARTED, FETCH_COMPLETE and FETCH_ERROR. How would you deal with cases where you need to fetch multiple data sources then combine them? Seems like the number of actions would quickly explode. Also, how would you deal with dependencies and errors? - the service api: context.service.read('message', {}, {}, function (err, messages) too many optional params, kinda hard to keep track what goes where. I'd prefer something with promises. - I also miss query params support in fluxible router

hleszek 12y ago

So, which one do you prefer and why ?

hoodoof 12y ago

Is there a conclusion, comparison or a point? I'm interested in the outcome but not trawling through the links and stuff.

ksmtk 12y ago
there will be summing up article soon, but that's not the main point
- cies 12y ago
  I would also like your know thoughts on how they compare.

danesparza 12y ago

I'm surprised to discover how useful I found this -- being able to compare roughly 'apples to apples' in an app was very helpful. Thank you for your efforts!

Ronsenshi 12y ago

Great job! It's nice to be able to compare same application elements written in different frameworks - very illustrative. Can't wait for the post with conclusion and thoughts on this.

mukmuk 12y ago

@prottmann alluded to it, but it might be useful to add Marty as well (http://martyjs.org http://martyjs.org) (no affiliation). It's just behind Reflux on the superficial metrics (stars, contributors, npm downloads) so is likely to be on most short-lists. I've had a good experience with Marty so far but remain curious about the others. Reflux worries me a bit because of its minor divergences from the Flux design decisions.

uxtemple 12y ago
Same thing here. Marty is proving to be very good and flexible so far while providing a rather succinct implementation overall. +1
jfhollingworth 12y ago
I've opened a PR for it but it needs to be merged in https://github.com/voronianski/flux-comparison/pull/5 https://github.com/voronianski/flux-comparison/pull/5
ksmtk 12y ago
marty example is added to repo - https://github.com/voronianski/flux-comparison/tree/master/marty https://github.com/voronianski/flux-comparison/tree/master/m...
mercer 12y ago
Could you elaborate on your worries? I've used Reflux because it simplified certain things, and I'd love to understand the drawbacks.

namuol 12y ago

It's great to see more example Flux projects using different implementations, but what we really need is just one larger and more sophisticated app example. I've been adapting a React-based app to the Flux architecture for the last week or two. I constantly find myself scratching my head, especially regarding asynchronous operations that need to be reflected in the View. It would be nice for the mock API in these examples to "simulate" a poor network connection in order to see how asynchronous error handling is best handled in each implementation, for instance.

jfhollingworth 12y ago
That's why we created https://github.com/jhollingworth/marty-chat-example https://github.com/jhollingworth/marty-chat-example. It's got proper examples of using HTTP & WebSockets
- namuol 12y ago
  Ha, I actually submitted an issue to this yesterday. It's a good example but misses some really important (i.e. usually-confusing) stuff: error/failure handling and rollbacks.