4 ms·

I see that its using 'redux-router' which within the last few weeks is no longer the official binding between react router and redux. [0][1] Any plans to upgrad

I see that its using 'redux-router' which within the last few weeks is no longer the official binding between react router and redux. [0][1] Any plans to upgrade? 0:https://github.com/rackt/react-router-redux https://github.com/rackt/react-router-redux 1: https://github.com/acdlite/redux-router https://github.com/acdlite/redux-router

yrashk 11y ago
From react-router-redux's readme: redux-router is another project which solves the same problem. However, it's far more complex. Take a quick look at the code for this library—it's extremely minimal. redux-router is much bigger and more complex. That said, redux-router is a fine project and has features this doesn't provide. Use it if you like it better.
subpixel 11y ago
This reminds me of why I switched away from React. I spent two weeks on a tutorial, and by the third week all of its recommendations had fallen out of favor. And here a project is created to provide some sort of stable React-based framework, and it's "doing routing wrong". YMMV but for me React's good parts did not overcome the frustration of feeling like I was building on sand. I don't mean to say React is unstable - React is great. It's just that the ecosystem and tooling is too ephemeral for me. Life this too short to worry about whether x, which I incorporated into by processes yesterday, will be supplanted by y tomorrow.
- colordrops 11y ago
  What did you end up using?
  - subpixel 11y ago
    I don't want to proselytize. Every choice is a trade-off. And project needs sometimes dictate technological decisions. But this post touches on many of the reasons I've landed on Ember: https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc53#.8upmfsv1a https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc5...
- aarpmcgee 11y ago
  The names are all so similar. Incredibly frustrating.
- szines 11y ago
  For the same reason I switched to Ember.js. I prefer the more opinionated way, the conventions. It looks to me, this repo try to provide some structure, but this is only one from the other 25 projects which do the same. The development effort is so fragmented. Should focus only one good react based framework. Luckily Ember.js is already implemented the good parts from React and from the Flux concept, stable, production ready, huge community. When you work with Ember, you dont feel that "fatigue" bullshit, because it is just disappeared. ;)
  - sotojuan 11y ago
    I'm looking into switching to Ember... The simple React stuff I've made its fun but it looks like too much trouble for big stuff. Also Ember is getting server side rendering.
    - szines 11y ago
      Yep, great choice. I've just updated my free Ember.js tutorial, if you would like to learn more about it: http://yoember.com http://yoember.com I'm playing with the server side rendering nowadays, and it is promising. It will be easy to use and nicely integrated with the whole ecosystem. This blog post is not short, but you can get a view, what is the core team's plan for the next couple of weeks, and how the framework evolve further this year. http://emberjs.com/blog/2016/01/23/core-team-face-to-face-january-2016.html http://emberjs.com/blog/2016/01/23/core-team-face-to-face-ja...
  - Geee 11y ago
    How is performance like on Ember.js? Because that's one of the reasons I'm switching from Angular. In React I think I have better and easier control of performance, because I mostly know what's going on.
    - szines 11y ago
      Yes, you right, if you need only a simple component, React is almost the fastest. However, if you have a couple of level deep nested structure, nested components, React perform very badly. Probably Ember.js will never be the fastest framework on todo list performance test. However in complex application, it is fast, or maybe faster than any other solution. The Glimmer Engine 2 is on the way, will be released in a couple of weeks with backward compatibility. So if you built an Ember.js app before, it will enjoy this performance boost as well. And improving performance will never stop, so it is just getting better, meanwhile the developer happiness is on the top, thanks to Ember ecosystem, the add-ons, the Ember-CLI, etc... In most of the projects the importance of the speed of rendering a tiny component is insignificant comparing to the speed of the network, or to the importance of the management of model/serialisers/adapters, or to dealing with app router/services, or to the importance of testing and deployment. Ember.js project's main goal is providing a complex solution, where the developer has to focus only to ship a product, building features and release it. Ember achieved this goal more than a year ago, the whole framework is matured, more production and corporate ready than any other solution out there at the moment. A great presentation about how intercom.io can ship fast thanks for Ember.js: https://www.youtube.com/watch?v=fVwDuMGVhYY&sns=tw https://www.youtube.com/watch?v=fVwDuMGVhYY&sns=tw Nice comparison of renderers: https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/ https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-in...
- capkutay 11y ago
  I think anything recommended by Dan Abramov is safe to use. I'm not a fan of the popular react/redux boilerplates because most of them are very opinionated. Many boilerplate authors will actually invent new conventions within the boilerplate (e.g. use my new framework to do API calls). Yet their code is left uncommented and they assume you will just believe that their conventions are actually beneficial to follow. You're better off just starting from scratch. I was once down-voted heavily on HN for saying the React ecosystem seems immature (this was about a year ago). A year later, it still seems like there's no consensus on how to build scalable apps with react.

yrashk 11y ago

From react-router-redux's readme: redux-router is another project which solves the same problem. However, it's far more complex. Take a quick look at the code for this library—it's extremely minimal. redux-router is much bigger and more complex. That said, redux-router is a fine project and has features this doesn't provide. Use it if you like it better.

subpixel 11y ago

This reminds me of why I switched away from React. I spent two weeks on a tutorial, and by the third week all of its recommendations had fallen out of favor. And here a project is created to provide some sort of stable React-based framework, and it's "doing routing wrong". YMMV but for me React's good parts did not overcome the frustration of feeling like I was building on sand. I don't mean to say React is unstable - React is great. It's just that the ecosystem and tooling is too ephemeral for me. Life this too short to worry about whether x, which I incorporated into by processes yesterday, will be supplanted by y tomorrow.

colordrops 11y ago
What did you end up using?
- subpixel 11y ago
  I don't want to proselytize. Every choice is a trade-off. And project needs sometimes dictate technological decisions. But this post touches on many of the reasons I've landed on Ember: https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc53#.8upmfsv1a https://medium.com/@jonpitch/ember-get-shit-done-36383c2ccc5...
aarpmcgee 11y ago
The names are all so similar. Incredibly frustrating.
szines 11y ago
For the same reason I switched to Ember.js. I prefer the more opinionated way, the conventions. It looks to me, this repo try to provide some structure, but this is only one from the other 25 projects which do the same. The development effort is so fragmented. Should focus only one good react based framework. Luckily Ember.js is already implemented the good parts from React and from the Flux concept, stable, production ready, huge community. When you work with Ember, you dont feel that "fatigue" bullshit, because it is just disappeared. ;)
- sotojuan 11y ago
  I'm looking into switching to Ember... The simple React stuff I've made its fun but it looks like too much trouble for big stuff. Also Ember is getting server side rendering.
  - szines 11y ago
    Yep, great choice. I've just updated my free Ember.js tutorial, if you would like to learn more about it: http://yoember.com http://yoember.com I'm playing with the server side rendering nowadays, and it is promising. It will be easy to use and nicely integrated with the whole ecosystem. This blog post is not short, but you can get a view, what is the core team's plan for the next couple of weeks, and how the framework evolve further this year. http://emberjs.com/blog/2016/01/23/core-team-face-to-face-january-2016.html http://emberjs.com/blog/2016/01/23/core-team-face-to-face-ja...
- Geee 11y ago
  How is performance like on Ember.js? Because that's one of the reasons I'm switching from Angular. In React I think I have better and easier control of performance, because I mostly know what's going on.
  - szines 11y ago
    Yes, you right, if you need only a simple component, React is almost the fastest. However, if you have a couple of level deep nested structure, nested components, React perform very badly. Probably Ember.js will never be the fastest framework on todo list performance test. However in complex application, it is fast, or maybe faster than any other solution. The Glimmer Engine 2 is on the way, will be released in a couple of weeks with backward compatibility. So if you built an Ember.js app before, it will enjoy this performance boost as well. And improving performance will never stop, so it is just getting better, meanwhile the developer happiness is on the top, thanks to Ember ecosystem, the add-ons, the Ember-CLI, etc... In most of the projects the importance of the speed of rendering a tiny component is insignificant comparing to the speed of the network, or to the importance of the management of model/serialisers/adapters, or to dealing with app router/services, or to the importance of testing and deployment. Ember.js project's main goal is providing a complex solution, where the developer has to focus only to ship a product, building features and release it. Ember achieved this goal more than a year ago, the whole framework is matured, more production and corporate ready than any other solution out there at the moment. A great presentation about how intercom.io can ship fast thanks for Ember.js: https://www.youtube.com/watch?v=fVwDuMGVhYY&sns=tw https://www.youtube.com/watch?v=fVwDuMGVhYY&sns=tw Nice comparison of renderers: https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/ https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-in...
capkutay 11y ago
I think anything recommended by Dan Abramov is safe to use. I'm not a fan of the popular react/redux boilerplates because most of them are very opinionated. Many boilerplate authors will actually invent new conventions within the boilerplate (e.g. use my new framework to do API calls). Yet their code is left uncommented and they assume you will just believe that their conventions are actually beneficial to follow. You're better off just starting from scratch. I was once down-voted heavily on HN for saying the React ecosystem seems immature (this was about a year ago). A year later, it still seems like there's no consensus on how to build scalable apps with react.