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?
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.
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.
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. ;)
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.
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.
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.
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.
This looks great for some projects, but the very problem it's trying to solve --abstraction of dependencies in a rapidly changing ecosystem -- makes it too rigid and imminently outdated for many projects. Case in point, react-router-redux vs redux-router. It's unclear in the documentation on how to swap out components or include other plugins like sass-loader without forking.
But this could be a great tool to fork and use across several related projects to manage dependencies on one place. Thanks for posting it!
I think this is a really exciting project and will definitely be paying attention to it over time. There's been so many "Javascript fatigue" articles and I think projects like these help solve issues stitching up many small npm libraries together to make a cohesive web app. Even if you're familiar with all the libraries in the React/Redux/Webpack ecosystem (and I'm not - I've only used React & Redux for small side projects), I think there's a tremendous value in knowing that these sets of libraries at these versions are compatible with each other.
While it's nice to have small dependencies that you can swap out over time as your use case evolves or as the ecosystem progresses, most of the time I'd just like to use the "standard stack" for a given platform. As someone who primarily uses Angular, one of the main benefits I see of Angular's 'kitchen-sink' approach is that you get a lot of standard functionality right out of the box (e.g. routing, i18n, animation) without having to research the best community package for that particular functionality. However, I think it's the narrow focus of React on the 'View' layer that's made it so widely adopted, because it plays well with an existing stack.
Having a project like this seems like the best of both worlds - libraries like React can focus on excelling in a single concern and developers still get a curated set of standard functionality so they can setup a complete web app.
Thanks! This project was born out of my personal frustration (I tried many boilerplates, wasn't happy with either and hated the fork-and-forget approach). I am already using it for some real projects myself. If it will be useful for anybody else — that'll be great!
I browsed through the README and was somewhere between laughing and crying by the end - it's like a case-study for all the baffling complexity that's been added to front-end development over the last two or three years.
(I expect this comment won't be too popular, but I'm happy to take the flak.)
Its the single page app tax. To be honest I find it infinitely more complex than a standard old school front end but I'm also happy to pay the tax and reap the benefits in the end. Not to mention it makes things more interesting from a pure dev fun point of view.
If there are any sane people left, please ignore these boilerplate kits. If you need React or a similar lib, and you know how to use it, you should probably research the libs available and pick your own front-end toolkit. There are no standards (that you can rely upon).
If you don't need this crap to show that your user is logged in, or if you don't know how React (and its baggage) even works, steer clear. You'll lose your time and sanity pursuing a transient, subpar solution to a problem you may not ever have.
I implore everybody justifiably interested in React to try Mithril or Cycle.js first. Both represent saner approaches.
I can agree with you about steering clear of such a large boilerplate setup-- especially if you don't understand everything baked in. But can you explain why you would choose Mithril of Cycle.js over React?
I've been building production apps with React for about a year but at a glance I can't really see any clear advantages in Mithril or Cycle.js
I can speak to Cycle, at least. The big deal for Cycle is that it is reactive programming using RxJS. RxJS provides a standardized (and cross-language [1]) "standard language" of working with reactive flows. It's very nice to have a reusable "toolbox" like RxJS and knowing that the skills you put into using it transfer to just about any other language you might want to use (and vice versa, I first used RX in C#). While there are RxJS integrations into React, the benefit to Cycle is that in presuming (and building explicitly on top of) RxJS it ends up being a relatively small "glue library" and a set of documented conventions for RX observables ("event streams"), more than a complicated chunk of "framework code".
Interesting. I'm a fan of reactive programming and I've built projects using react+bacon.js and found that they worked well together. I'll have to give cycle a try on a hobby project sometime.
Unfortunately I'm shoe horned into react for my client work. The majority of my projects are handed off to the client to maintain and React is sort of a selling point (because.. you know facebook uses it and all). I'm afraid I can't realistically sell Cycle.js at this point.
Yeah, I definitely understand the salesmanship "follow the other lemmings" aspect of things. If it helps, I've found that I can sell "This project should use RX for all of these good reasons and its a growing industry standard supported by companies like Microsoft and Netflix..." and if I need to mention Cycle at all directly, pointing out Cycle is just the handy "glue" to bind RxJS to a Virtual DOM similar to Facebook's React...
This has been my primary concern and the reason for which I avoid boilerplate kits except to study them:
> Fork-and-forget (or fork-and-follow) is not a great way to keep up with what's happening in the original boilerplate (and in the space in general). Therefore, starting off a cloned boilerplate "kit" is not an acceptable solution. Reactuate is distributed as a dependency.
I am interested in understanding why the author chose not to use yeoman ? Wouldn't it be nice to get things like support for interactive generators for free -- while retaining the ability to compose and update ?
IMHO it's a pity that the author of Redux - who is doing a GREAT job btw - doesn't want Redux to be a bit more opinionated itself. For example adopting Immutable by default. Maybe I wouldn't have liked some his choices, but at least it would be much easier to create coherence in the community and an easier path for newcomers.
I that is a simple, isolated component. The difference between Redux, and say this project, is I can use redux on the frontend, the backend, and with react-native because it is so simple.
32 comments
[ 2671 ms ] story [ 210 ms ] thread0:https://github.com/rackt/react-router-redux
1: https://github.com/acdlite/redux-router
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.
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.
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-ja...
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
Nice comparison of renderers: https://auth0.com/blog/2015/11/20/face-off-virtual-dom-vs-in...
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.
But this could be a great tool to fork and use across several related projects to manage dependencies on one place. Thanks for posting it!
While it's nice to have small dependencies that you can swap out over time as your use case evolves or as the ecosystem progresses, most of the time I'd just like to use the "standard stack" for a given platform. As someone who primarily uses Angular, one of the main benefits I see of Angular's 'kitchen-sink' approach is that you get a lot of standard functionality right out of the box (e.g. routing, i18n, animation) without having to research the best community package for that particular functionality. However, I think it's the narrow focus of React on the 'View' layer that's made it so widely adopted, because it plays well with an existing stack.
Having a project like this seems like the best of both worlds - libraries like React can focus on excelling in a single concern and developers still get a curated set of standard functionality so they can setup a complete web app.
I see what you did there.
(I expect this comment won't be too popular, but I'm happy to take the flak.)
The action is defined like this:
const IncrementCounter = createAction(domain, 'IncrementCounter',t.maybe(incrementParameter))
(A oneliner)
> appendices
If there are any sane people left, please ignore these boilerplate kits. If you need React or a similar lib, and you know how to use it, you should probably research the libs available and pick your own front-end toolkit. There are no standards (that you can rely upon).
If you don't need this crap to show that your user is logged in, or if you don't know how React (and its baggage) even works, steer clear. You'll lose your time and sanity pursuing a transient, subpar solution to a problem you may not ever have.
I implore everybody justifiably interested in React to try Mithril or Cycle.js first. Both represent saner approaches.
I've been building production apps with React for about a year but at a glance I can't really see any clear advantages in Mithril or Cycle.js
[1] http://reactivex.io
Unfortunately I'm shoe horned into react for my client work. The majority of my projects are handed off to the client to maintain and React is sort of a selling point (because.. you know facebook uses it and all). I'm afraid I can't realistically sell Cycle.js at this point.
https://news.ycombinator.com/newsguidelines.html
> Fork-and-forget (or fork-and-follow) is not a great way to keep up with what's happening in the original boilerplate (and in the space in general). Therefore, starting off a cloned boilerplate "kit" is not an acceptable solution. Reactuate is distributed as a dependency.
I am interested in understanding why the author chose not to use yeoman ? Wouldn't it be nice to get things like support for interactive generators for free -- while retaining the ability to compose and update ?