Hacker News Reader

Comment by vdnkh | Hacker News Reader

What's wrong with vanilla React/Flux? I'm currently working on a greenfield project and I've more or less settled settled on that stack. I have immense respect for Abramov but I'm finding it hard to justify Redux when Flux works well.

View on HN

vanilla flux has WAAAAAAAAAAAAAAAAAY more boilerplate than redux

I'd gladly trade more boilerplate for stability and confidence of non-breaking updates. You can also write higher-order components to DRY things up.

It's not the boilerplate that get's me. It's just easier to reason about the state using Redux (imho). The idea of 1 single global state which mutates and pushes down (instead of managing observables all over), makes it easier to see when/where something changes. The idea isn't new (check react-cursor for example).

That said, there's nothing wrong with vanilla flux. Just that I find redux much easier to understand and follow.

Also that!

I haven't really found redux to be all that unstable, though.

Redux is literally ~100 lines of code (you can check out Dan Abramov's Egghead.io series about it in which he basically rebuilds Redux).

I'm among the many people who previously used vanilla flux and prefer what the Redux style brings to it.

I wrote a little about it: http://stackoverflow.com/questions/32461229/why-use-redux-ov...

Redux has good tools. You can restore your state after hot-reloading your changed JavaScript code. You can do time-traveling to restore your app state in any point of time (using new code) but old state. IMO that's an incredible improvement for development.

Reply on news.ycombinator.com