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.
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.”
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
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...