4 ms·

Go / Postgres / React & Fluxxor Edit: forgot to mention go-tigertonic. :)

brotchie 12y ago
Node.js / Express / Postgres / React & Fluxxor Really enjoying the Flux design pattern + declarative nature of React. I've been applying the Flux pattern to other applications (iOS) with great successful. The goal of one-way data flow and a single touch point for application events is a radical tool for complexity reduction.
- yror10 12y ago
  Are you using any ORM for PostgreSQL in Node? Haven't found anything as good as ActiveRecord yet...
  - chinedufn 12y ago
    Check out bookshelf and knex
swah 12y ago
I'm trying to use Go+React and had not heard about Fluxxor. How do those (Golang and Fluxxor which is based on Node) fit together in your system? Are you using a Node or Go frontend?
- randallsquared 12y ago
  We're using Fluxxor on the client, not the server. It uses node for installation infrastructure, but after you bundle it up it's just another JS library to import with require.js (or whatever; it's agnostic about such things).
glis 12y ago
I just looked at Fluxxor and AngularJS. They use the exact same TodoList example in their quickstart guides. Turns out that AngularJS is simpler and easier to understand.
- girvo 12y ago
  As someone who uses Angular.js every single day on some very large front-end apps, yeah, Angular seems simpler to understand, until your app gets large; Those small examples don't really show the benefit of the Flux architecture, as when it's that small something like Angular or other MVC frameworks with their magic and libraries really shine. Heck, Angular is still excellent for large apps as well, as long as there is discipline in your development technique. The issue arises when you have a large team with varying skill levels, all working on the same front-end, with things stuck in the $scope when they shouldn't be, over-use and abuse of $watch, and a stack of other gotchas that make debugging an absolute nightmare, as tracing the execution flow is nigh on impossible. That's where Flux is trying to do things differently. By having one way of passing data between the various components (and plugged directly into React, which also is built around a "componentized" architecture) you know exactly where to look when things go wrong, you give up a bit of dynamism and magic for explicitness, which in my experience is not a bad thing. That's my two cents anyway!

Node.js / Express / Postgres / React & Fluxxor Really enjoying the Flux design pattern + declarative nature of React. I've been applying the Flux pattern to other applications (iOS) with great successful. The goal of one-way data flow and a single touch point for application events is a radical tool for complexity reduction.

yror10 12y ago
Are you using any ORM for PostgreSQL in Node? Haven't found anything as good as ActiveRecord yet...
- chinedufn 12y ago
  Check out bookshelf and knex

swah 12y ago

I'm trying to use Go+React and had not heard about Fluxxor. How do those (Golang and Fluxxor which is based on Node) fit together in your system? Are you using a Node or Go frontend?

randallsquared 12y ago
We're using Fluxxor on the client, not the server. It uses node for installation infrastructure, but after you bundle it up it's just another JS library to import with require.js (or whatever; it's agnostic about such things).

glis 12y ago

I just looked at Fluxxor and AngularJS. They use the exact same TodoList example in their quickstart guides. Turns out that AngularJS is simpler and easier to understand.

girvo 12y ago
As someone who uses Angular.js every single day on some very large front-end apps, yeah, Angular seems simpler to understand, until your app gets large; Those small examples don't really show the benefit of the Flux architecture, as when it's that small something like Angular or other MVC frameworks with their magic and libraries really shine. Heck, Angular is still excellent for large apps as well, as long as there is discipline in your development technique. The issue arises when you have a large team with varying skill levels, all working on the same front-end, with things stuck in the $scope when they shouldn't be, over-use and abuse of $watch, and a stack of other gotchas that make debugging an absolute nightmare, as tracing the execution flow is nigh on impossible. That's where Flux is trying to do things differently. By having one way of passing data between the various components (and plugged directly into React, which also is built around a "componentized" architecture) you know exactly where to look when things go wrong, you give up a bit of dynamism and magic for explicitness, which in my experience is not a bad thing. That's my two cents anyway!