
Show HN: Reactuate – a React/Redux stack with a focus on domain-driven design - yrashk
https://github.com/reactuate/reactuate
======
willchen
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.

~~~
yrashk
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!

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

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

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

~~~
yrashk
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)

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

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

~~~
szines
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.
;)

~~~
Geee
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
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-in...](https://auth0.com/blog/2015/11/20/face-off-virtual-dom-
vs-incremental-dom-vs-glimmer/)

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

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

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

~~~
r-cid
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

~~~
WorldMaker
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](http://reactivex.io)

~~~
r-cid
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.

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

------
lf-non
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 ?

------
simple10
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!

------
jzig
> some things are in a flux

I see what you did there.

