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.<p>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.<p>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 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.<p>(I expect this comment won't be too popular, but I'm happy to take the flak.)
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?<p>0:<a href="https://github.com/rackt/react-router-redux" rel="nofollow">https://github.com/rackt/react-router-redux</a><p>1: <a href="https://github.com/acdlite/redux-router" rel="nofollow">https://github.com/acdlite/redux-router</a>
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.
> front-end development<p>> appendices<p>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).<p>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.<p>I implore everybody justifiably interested in React to try Mithril or Cycle.js first. Both represent saner approaches.
This has been my primary concern and the reason for which I avoid boilerplate kits except to study them:<p>> 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.<p>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 ?
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.<p>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!