yawn. another stack. what are its merits?
The article is about that.
The 3REE Stack: React, Redux, RethinkDB and Express.js
11–20 of 21 posts
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#123 shiny new techs, and one clunky older one. Why use Express.js instead of its successor Koa.js?
In my React (+Redux) applications, Express only plays a very minor part of being the entry point for the server.
Check this out https://github.com/joshhunt/reactapus/blob/master/src/server.... Koa or Express.js wouldn't really make that much of a difference.
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#133 shiny new techs, and one clunky older one. Why use Express.js instead of its successor Koa.js?
In my React (+Redux) applications, Express only plays a very minor part of being the entry point for the server. Check this out https://github.com/joshhunt/reactapus/blob/master/src/server... . Koa or Express.js wouldn't really make that much of a difference.
If there is no server side functionality, why not use one of the many react static site generators?
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#14Earlier quoted context omitted.
In my React (+Redux) applications, Express only plays a very minor part of being the entry point for the server. Check this out https://github.com/joshhunt/reactapus/blob/master/src/server... . Koa or Express.js wouldn't really make that much of a difference.
If there is no server side functionality, why not use one of the many react static site generators?
Because this isn't a static site. Updates are being fed to the client via websockets.
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#15Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#16Earlier quoted context omitted.
If there is no server side functionality, why not use one of the many react static site generators?
Because this isn't a static site. Updates are being fed to the client via websockets.
But neither koa.js nor express.js do websockets. You're holding up a site that would probably be simpler without both koa and express as an example to say that it doesn't make much of a difference whether you choose koa.js or express.js.
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#17Earlier quoted context omitted.
Because this isn't a static site. Updates are being fed to the client via websockets.
But neither koa.js nor express.js do websockets. You're holding up a site that would probably be simpler without both koa and express as an example to say that it doesn't make much of a difference whether you choose koa.js or express.js.
We've built a pretty cool library for Express that makes it easy to do WebSocket stuff through Pushpin (a proxy server). http://blog.fanout.io/2015/03/09/stateless-websockets-with-e...
Not that this was covered in the article, but it would be a reason to choose Express as the backend. It would be cool to build something similar for Koa though.
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#18"However, out of this wonderfully frustrating evolution of JavaScript I think things are beginning to settle down."
React - first commit May 29, 2013
Flux - first commit July 23, 2014
ExpressJS - first commit July 31, 2012
RethinkDB - first commit Oct 3, 2009
Yeah, I doubt it.
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#19I'm using React + Redux + Koa (+postgresql). The most annoying thing with JavaScript right now is that Babel gives you all ES6 features in your front end bundle, but node 4 only has a subset, so you have to remember when you to stop using features. (No I don't want to transpile back end code).
Re: The 3REE Stack: React, Redux, RethinkDB and Express.js
#20I'm using React + Redux + Koa (+postgresql). The most annoying thing with JavaScript right now is that Babel gives you all ES6 features in your front end bundle, but node 4 only has a subset, so you have to remember when you to stop using features. (No I don't want to transpile back end code).
You can use Babel with node on the back end. See https://babeljs.io/docs/usage/require/. Definitely not the most ideal solution, but it allows you to easily transition into ES6 when all the features land in node.