Show HN: Reactuate – a React/Redux stack with a focus on domain-driven design | Hacker News Reader

Show HN: Reactuate – a React/Redux stack with a focus on domain-driven design

github.com

49 pointsyrashk32 comments

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!

Ignore the haters. I can't fathom why you would be down voted. Keep up the great work. I will be following your project with interest.

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.)

"Now, we should define an increment action." <TYPING INTENSIFIES>. 40 lines of code later, we can increment a variable.

This project is written as a literate program and most important parts of the code are exposed. What you see there is how it's actually implemented.

The action is defined like this:

const IncrementCounter = createAction(domain, 'IncrementCounter',t.maybe(incrementParameter))

(A oneliner)

to address this confusion, I've added an "excerpt from the library" label to show which parts of the code are just parts of the actual stack.

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.

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

1: https://github.com/acdlite/redux-router

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.

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.

What did you end up using?

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-36383c2ccc5...

The names are all so similar. Incredibly frustrating.

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.

Yep, great choice. I've just updated my free Ember.js tutorial, if you would like to learn more about it: 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-ja...

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.

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 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.

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.

Do you mean Immutable.js? Would be cool, but it's pretty heavy. It's 56kb minified.

> front-end development

> 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 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".

[1] http://reactivex.io

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...

Please don't bait other users by inviting them to downvote you or announce that you expect to get downvoted.

https://news.ycombinator.com/newsguidelines.html

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 ?

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!

> some things are in a flux

I see what you did there.

Reply on news.ycombinator.com