FUfunerr·Jan 3, 2016Submission
2 points · Open discussionpluma
fynx
JavaScript2014–2016
pluma / fynx · Archived
fynx
UNMAINTAINED. Formerly known as Flox.
5Distinct people
5Mentions
0Explicit recommenders
278GitHub stars
What to know before exploring
What it is
UNMAINTAINED. Formerly known as Flox.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month5 dated mentions
Observed mentions: 2014-10-29 12:45:44 UTC to 2016-01-03 13:21:03 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Oct 2014 | 2014-10-01 00:00:00 UTC | 2014-11-01 00:00:00 UTC | 1 | 0 | 1 |
| Nov 2014 | 2014-11-01 00:00:00 UTC | 2014-12-01 00:00:00 UTC | 1 | 1 | 0 |
| Dec 2014 | 2014-12-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 1 | 1 |
| Jan 2015 | 2015-01-01 00:00:00 UTC | 2015-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2015 | 2015-02-01 00:00:00 UTC | 2015-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2015 | 2015-03-01 00:00:00 UTC | 2015-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2015 | 2015-04-01 00:00:00 UTC | 2015-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2015 | 2015-05-01 00:00:00 UTC | 2015-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2015 | 2015-06-01 00:00:00 UTC | 2015-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2015 | 2015-07-01 00:00:00 UTC | 2015-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2015 | 2015-08-01 00:00:00 UTC | 2015-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2015 | 2015-09-01 00:00:00 UTC | 2015-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2015 | 2015-10-01 00:00:00 UTC | 2015-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2015 | 2015-11-01 00:00:00 UTC | 2015-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2015 | 2015-12-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2016 | 2016-01-01 00:00:00 UTC | 2016-02-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
5 sourcesBut you can also get om in javascript with something like omniscient[1]/immutable[2], or fynx[3] for flux with immutable.
Though I agree both clojurescript and elm look nice, I'd bet you a lot of money they won't be _the_ technologies in 2015.
[1] https://github.com/omniscientjs/omniscient
[2] https://github.com/facebook/immutable-js
[3] https://github.com/foss-haas/fynx
In No more JavaScript frameworksFynx – architecture library for React inspired by Reflux and Fluxxor
2 points · Open discussionYet another Flux-like for React
1 points · Open discussionI'm using React. My server-side rendering is essentially `React.renderComponentToString(App(data))`. The only difference between how I invoke my app on the server vs on the client is that instead of `React.renderComponent` I use `React.renderComponentToString`. On the client, React just uses the pre-rendered HTML and binds itself to that without re-rendering a single DOM node.
All my scripts are in `package.json`. I don't use Grunt or Gulp. If I want to re-bundle my client, I invoke a script that essentially does `browserify -g uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the bundler script are automatically invoked by a watcher.
This[0] is my entire build script and the only reason it's verbose is because I like to be able to execute each task separately if I want to.
The only problem with React is that it is onl
Read the rest
y a view library. It only does components. The blessed solution is a Flux-like architecture as implemented by Fluxxor or Reflux, but you can integrate React into nearly anything you already have. I like the immutable/unidirectional approach React and Flux share and ended up writing my own library[1] because there were things I didn't like about the existing Flux implementations, but you don't have to do that.
I have to admit that Flux has a steep learning curve. And if you've never dealt with immutability before it can really melt your brain. But I don't see how Meteor is any easier to pick up, especially considering that it comes with its own entirely separate ecosystem (the only non-node library I use in my React app is an XHR-wrapper that replaces `request` on the client).
[0]: https://gist.github.com/pluma/61a1639906e188be8423
[1]: https://github.com/foss-haas/flox