Hacker News Reader

Comment by sircastor | Hacker News Reader

That's interesting, I started with React, and switched to Vue, and felt Vue was the simpler tool.

Agreed. When evaluating both of them, it looked like React and Vue implement the same concepts, but React did it in ways that made it more complicated than it needed to be. I specifically didn’t like that Redux and it’s docs were too heady for what it really is (it’s just event triggering and handling, why does it have to be so complicated?), and the fact that React didn’t have any official “here’s is how to build a complete app” docs. It was always “well here are different choices and project layouts you could use”. I don’t want to care about using this templating system or that. I want batteries included. Vue did that well.

Redux is an independent project from React. You could use redux with Vue. Your other points are valid but detracting from one library because people often use another you don’t care for seems outside the scope of React vs Vue.

Just for the record most people using vue would be using Vuex:

https://vuex.vuejs.org

Which IMO is simpler to understand as a newbie than Redux. Maybe because it had the luxury of coming after Redux/similar projects and underpinning a simpler parent framework.

Sounds as of 3.0 it became much simpler, as vuex doesn't sound as necessary.

I’ve yet to build a Vue app that I felt needed external state management (though admittedly none are huge SPAs) but I have felt the pain in React working on a similar sized project. Just something about how the events work out of the box. React I felt like I needed to pass in functions to change parent state through a callback function in props, whereas in Vue I just emit the event and forget about it.

You can still use the function prop pattern in Vue but it doesn’t make much sense when event emission is so much simpler to reason about.

I purposefully avoid Vuex until a) the state becomes large or b) deeply nested objects (which reacitivity handles poorly, as whole trees rerender) or c) when I have lots of deep nested Components with a maze of events.

This is where I've found Vuex is a life saver for reducing complexity, organizing state in a seperate area, and having a consistent interface for accessing/mutating data without a tangled web of events and functions across multiple files/layers.

Redux is at its core super simple.

Action handler gets data, does business logic stuff, sends result off to reducer that publishes the data back to the UI layer.

Online explanations of this suck.

For me, how vuex works was very very easy to visualize. State, mutations and actions are very intuitive.

On the other hand, redux's reducers are harder to visualize at the beginning. Until you learn how the reducer works, every reference to "reducer" leaves you slightly confused.

I visualized redux's better with a simple example. It helps you to see how state and reducers interact.

Long before learning of React or redux I built a similar system to do IPC between two embedded MCUs.

All state was owned by the master MCU, slave MCU sent messages to the master requesting changes of state, the entire state for the slave CPU was then sent over with the requested changes.

Even what UI screen was shown was handled this way.

I was much more junior then, so the entire system wasn't event driven, all state was transferred every 33ms (iirc).

Redux is moderately more complex than that system, although my system was built in pure C and involved interop between C and C# running in an interpreter.

What I like about react is that it's batteries NOT INCLUDED, allowing me to choose tools best fit to the job. I think it's good that there's a healthy choice between vue and react, however!

Hi, I'm a Redux maintainer. FWIW, we're looking at revamping the Redux docs in the near future (see https://github.com/reduxjs/redux/issues/2590 for plans ).

If you've got any specific suggestions for improvements, please let us know! I'm always looking for ways we can make the docs better.

As a side note, React is separate from Redux, and Redux is definitely not tied to React. Here's a recent post about a team that opted to use Redux with Vue: https://snipcart.com/blog/redux-vue .

Sorry I just saw this. If you see this comment, yes I know Redux and React are separate and that you can use other state management systems besides Redux with React. However, that doesn’t help when evaluating the React ecosystem at first. I don’t want to play “pick a library, build a framework”. What I do most of the time is pretty common stuff: SPA with login, CRUD data manipulation, etc. I want a a framework that does 80% of that and has flexibility to create the other 20%. Many React/Redux tutorials are happy to oblige. But they are also all incomplete and unofficial. And by the time a large comprehensive tutorial is written by some kind soul, the APIs have changed, and you are back to SO looking for how to make the damn thing run.

Specifically with Redux, I would suggest clarifying stuff around reducers and possibly renaming them. As is, reducers sound like “a monad is a monoid in the class of ...” Vuex specifically does a very nice job of calling their equivalent thing “mutations” which is more intuitive.

My visualization of Redux/Vuex is basically an application of the event system to state management. Instead of manipulating global.state.foo directly, you ask the system to change the value of foo and a callback does it. A simple explanation like that from the start with some examples of benefits of it would be really helpful.

Also, Vuex has a less strict but more usable idea of not having to import actions. You just refer to them as strings.

Also also, examples of XHR/promises handled by Redux especially with error handling all the way from “server returned 404/400/500/etc.” to how to hand that off to a UI element would be helpful. Takes way too long to discover the right pattern for action returning a promise.

Redux is an incredibly simple idea, I have no clue why every explanation of it sucks.

The naming doesn't help.

"Reducers" is just so academic. Maybe a term like "publishers"?

Of course passing data by props instead of receiving a lambda is a bit of a different paradigm already. Takes some getting used to.

Same here!

Reply on news.ycombinator.com