Controversial opinion: Redux (and the Elm architecture behind it) only works with a typed language like TypeScript (or Elm) which takes away the error-prone part. With good type completion, some of the "pretty tedious" part goes away as well.

You're probably right about Elm which is basically one big reducer, but Redux adds a whole lot more indirection on top of that which makes it much more complicated.

Even small Redux apps can start off with a lot of indirection as soon as they extract logic into selectors. This is probably the first area where Redux becomes more complex that what you were doing before:

https://redux.js.org/usage/deriving-data-selectors

It reminds me of reading a bunch of parser combinators: it feels like you're reading code that builds something that does what you want instead of the code that just does what you want.

    const makeSelectItemsByCategory = () => {
      const selectItemsByCategory = createSelector(
        [state => state.items, (state, category) => category],
        (items, category) => items.filter(item => item.category === category)
      )
      return selectItemsByCategory
    }

Yeah, with Elm, when you handle an event, you either update the model (state) or you generate new events. You don't have this selector thing.

even with completion it's a lot of busywork: define actions, reducers, etc for every state change

If you use TypeScript and Thunk, it’s no more work than writing your own state management code on plain JS/TS objects. But you get all the advantages of Redux (dev tools, introspection, replayability, easy persistence and tab sync, etc).

Yeah strong typing is essential. Redux is overkill for small or even medium apps but it's the best tool I've found for dealing with the complexity of larger apps. Having a very clear, inspectable sequence of mutations to all your data becomes very valuable.

No. My team migrated to react from in 2015 because the biggest selling point was maintainability, not speed. The virtual DOM was originally marketed as why “react is NOT slow”. It was never about pure speed. I think the misconception all came later by other people.

> it was explicitly pushed and advertised as such

I'm sure React fans who misunderstood the virtual DOM (which was explicitly advertised because it was the most popular part of React[1] vs the other parts that people were more critical of) may have said this, but I never saw the project itself advertising itself as faster than vanilla JS, only that it could be faster than competing frameworks, _especially_ ones that rebuilt the DOM unnecessarily.

> I dunno, I used Redux for a few years

Redux is a different library than React. State management across an app is a problem even for non-React applications, it's not like React _uniquely requires_ work to address state management.

I don't see why your dissatisfaction with Redux has anything to do with React making a very specific and buggy part of building web apps easier to manage in return for a performance cost and following its API.

[1]: See mention near the end of https://medium.com/@dan_abramov/youre-missing-the-point-of-r...

It was a very common part of the marketing push, not just a few misguided fans. Here’s a former core team member:

https://svelte.dev/blog/virtual-dom-is-pure-overhead#how-did...

Here’s @vjeux: “React is a JavaScript library for building user interfaces developed by Facebook. It has been designed from the ground up with performance in mind.”

https://calendar.perfplanet.com/2013/diff/

“Optimized for performance and memory footprint”

http://slid.es/johnlynch/reactjs

If you worked on the web a decade ago, this stuff was everywhere and because Facebook was at its peak there was this bizarre reality-denial effect where people would have an app which was slow, soaked memory like a sponge, and they’d insist that was as good as it could be because Facebook and Instagram were using the same framework. Reality intruded enough eventually that people started talking more about things like developer experience but you can still find people arguing that needing 4MB of JavaScript for a contact form is normal.

None of those links say that React is faster than using no framework, just that it is fast, presumably compared to other frameworks or techniques before that did DOM replacement.

I guess you could say that not being specific was misleading but we'd have to agree to disagree on that. I _did_ work on the web a decade ago and my recollection is that it wasn't ever unclear that React's performance claims were that it was fast for a framework and not faster than equivalent manual DOM mutations.

> I _did_ work on the web a decade ago and my recollection is that it wasn't ever unclear that React's performance claims were that it was fast for a framework and not faster than equivalent manual DOM mutations.

That was a very common claim - if you search for old comments there was some very magical thinking about virtual DOMs at the time. I do agree it was worse in the fanboy circles - there’s a game of telephone where nuance is lost at every iteration so you’d sometimes have a blog post where someone said they saw a big win replacing a thicket of jQuery plugins and it’d eventually be repeated as “React is ZOMG FAST!!!!” with a few people trying in vain to suggest that replacing a bunch of organic code with something planned probably mattered more.

Anyway, my point isn’t that React is terrible but more that you really want to measure & review assumptions to make sure you’re not relying on something stale. It’s still easy to find assumptions from the IE6 era shaping what people think of as fast or slow, and especially with the massive front end framework trend it’s easy for people to have enough layers that their understanding of their application’s performance is far off. Choosing React is fine, just make the trade offs deliberately.

I do vaguely remember the Virtual dom was being advertised as faster. E.g. minimizing of updates by evaluating the dom-tree and e.g. moving entire branches. I dont think it was devs misreading intent here, maybe just in hindsight that dom-manipulation wasnt all that important of a bottleneck

> at the time React was introduced and started gaining traction was about the virtual DOM being "faster".

At the time it was. Especially compared to how apps were built at the time.

Note that even today virtual DOM libs (not the same implementation as React's) are still among the fastest: https://krausest.github.io/js-framework-benchmark/2024/table...

You now had to deal with react instead of the DOM. Mission accomplished.

Is this a parody?

Redux splits things up that belong together. Redux makes you write more code. Of course it's more complex.

Even it's creator advised that you probably don't need it.

> Even it's creator advised that you probably don't need it.

This is my whole point. Redux in itself is not complex. The elaborate flows people create with it are complex.

It's not Redux's fault that you're using it when you shouldn't be.

Store, selector, reducer, dispatch, action...

Redux is concept overload. It's abstractions on top of abstractions on top of abstractions...

It makes simple things complex.

If you liked Redux, you'll love the old J2EE!