3 ms·

>This is a very common misconception Not really a misconception: it was explicitly pushed and advertised as such, most of the advocacy (especially from React f

>This is a very common misconception Not really a misconception: it was explicitly pushed and advertised as such, most of the advocacy (especially from React fans) at the time React was introduced and started gaining traction was about the virtual DOM being "faster". >React changed things so that the state of the DOM is always derived from your own app's state, which eliminates what turned out to be a pretty tedious and error-prone amount of work in complex web apps. I dunno, I used Redux for a few years, and it was a "pretty tedious and error-prone amount of work in complex web apps" too.

the_gipsy 3y ago
You now had to deal with react instead of the DOM. Mission accomplished.
elbear 3y ago
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.
- agos 3y ago
  even with completion it's a lot of busywork: define actions, reducers, etc for every state change
  - pseudocomposer 3y ago
    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).
- cageface 3y ago
  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.
- deleted 3y ago
  [deleted]
- hombre_fatal 3y ago
  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 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 }
  - elbear 3y ago
    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.
Osmose 3y ago
> 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-react-a20e34a51e1a https://medium.com/@dan_abramov/youre-missing-the-point-of-r...
- trgn 3y ago
  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
- acdha 3y ago
  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-the-meme-start 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/ https://calendar.perfplanet.com/2013/diff/ “Optimized for performance and memory footprint” http://slid.es/johnlynch/reactjs 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.
troupo 3y ago
> 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_chrome_121.0.6167.85.html https://krausest.github.io/js-framework-benchmark/2024/table...
ZephyrBlu 3y ago
> I dunno, I used Redux for a few years, and it was a "pretty tedious and error-prone amount of work in complex web apps" too. This makes no sense. Redux is extremely simple with a very small API. If the code using it is tedious and error-prone, that's the fault of the people who wrote that code not Redux. E.g. "everything must be an action and have an associated reducer" is nothing to do with Redux itself.
- Sammi 3y ago
  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.
  - ZephyrBlu 3y ago
    > 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.
    - Sammi 3y ago
      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.
- coldtea 3y ago
  If you liked Redux, you'll love the old J2EE!
jinushaun 3y ago
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.

the_gipsy 3y ago

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

elbear 3y ago

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.

agos 3y ago
even with completion it's a lot of busywork: define actions, reducers, etc for every state change
- pseudocomposer 3y ago
  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).
cageface 3y ago
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.
deleted 3y ago
[deleted]
hombre_fatal 3y ago
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 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 }
- elbear 3y ago
  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.

Osmose 3y ago

> 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-react-a20e34a51e1a https://medium.com/@dan_abramov/youre-missing-the-point-of-r...

trgn 3y ago
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
acdha 3y ago
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-the-meme-start 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/ https://calendar.perfplanet.com/2013/diff/ “Optimized for performance and memory footprint” http://slid.es/johnlynch/reactjs 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.

troupo 3y ago

> 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_chrome_121.0.6167.85.html https://krausest.github.io/js-framework-benchmark/2024/table...

ZephyrBlu 3y ago

> I dunno, I used Redux for a few years, and it was a "pretty tedious and error-prone amount of work in complex web apps" too. This makes no sense. Redux is extremely simple with a very small API. If the code using it is tedious and error-prone, that's the fault of the people who wrote that code not Redux. E.g. "everything must be an action and have an associated reducer" is nothing to do with Redux itself.

Sammi 3y ago
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.
- ZephyrBlu 3y ago
  > 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.
  - Sammi 3y ago
    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.
coldtea 3y ago
If you liked Redux, you'll love the old J2EE!

jinushaun 3y ago

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.