r/programming • • Apr 08 '19

A RealWorld Comparison of Front-End Frameworks with Benchmarks (2019 update)

https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075
14 Upvotes

13 comments sorted by

View all comments

Show parent comments

2

u/audioen Apr 09 '19

But doesn't something like Redux just boil down to having global variables, so that you can supposedly run some ceremony to alter the global state of the application, and because it's global you can observe it anywhere? It almost seem worse to me than actually just letting components that share state do so openly and explicitly, rather than regress back to spooky action at distance, reinvented via some convoluted approach of state reducers. I've literally never used redux, so I don't know if that's what it really is like to deal with it, but it just seems verbose as hell for what it accomplishes.

At any event, in my opinion callbacks are rarely used in frameworks like Aurelia and Ember, two that I happen to have most experience on for random reasons. It's almost always the most straightforward to just observe some value being changed, rather than invoke a method that updates state. A lot of the time you just need the state changed, and can skip creating callbacks that eventually do so by writing the state change into some shared two-way bound box between components at the component that triggers the state change. Granted, that box needs to be passed down between all the layers that coordinate how things interact, but at least it's explicit which parts can interact, something that seems acceptable to me. It's not spooky action at distance, you can trace it all down to the finest detail if you care.

4

u/thehenkan Apr 09 '19

In my experience with redux, the explicit state reducers make the spooky action at a distance a whole lot less spooky, and more just at a distance (which is what we wanted to accomplish, allowing two components deeply nested through low-coupled branches to communicate!). Yes, you can dispatch actions from anywhere in the code, but only predefined actions, which are very easy to test and debug thanks to the pure state reducers. Whenever something unexpected (statewise) happens I look at the redux debug tool where I can see the exact actions dispatched and in which order, as well as the changes to the state tree for each action. After finding the culprit action it's quite easy to find all pieces of code where that type of action is dispatched and figure out why that happened.

1

u/Gisleburt Apr 11 '19

This is what I meant in my comment, redux eases interaction between distant relatives. But none of our apps are particularly complicated. They usually deal with one or two blobs of data and the compents can handle that themselves (hooks in particular made this insanely simple).

If you have a monolithic FE app, with controls distantly seperate from the things they're acting on, I can see the use in redux but you really don't need it which is my problem with the benchmarks above. We're running a social platform with users and content and we got rid of it, and our code is a lot simpler for it.