Reading this makes me even happier I decided on Phoenix LiveView a while back. React has become a behemoth requiring vendor specific hosting (if you want the bells and whistles) and even a compiler to overcome all the legacy.
Most of the time nobody needs this, make sure your database indexes are correct and don’t use some under powered serverless runtime to execute your code and you’ll handle more load than most people realize.
If you’re Facebook scale you have unique problems, most of us doesn’t.
I find the Krausest benchmarks[0] to be useful for these sorts of comparisons. There are always flaws in benchmarks, and this one particularly is limited to the performance for DOM manipulation of a relatively simple web application (the minimal VanillaJS implementation is about 50 lines of code). That said, Krausest and the others who work on it do a good job of ensuring the different apps are well-optimised but still idiomatic, and it works well as a test of what the smallest meaningful app might look like for a given framework.
I typically compare Vanilla, Angular, SolidJS, Svelte, Vue Vapor, Vue, and React Hooks, to get a good spread of the major JS frameworks right now. Performance-wise, there are definitely differences, but tbh they're all much of a muchness. React famously does poorly on "swap rows", but also there's plenty of debate about how useful "swap rows" actually is as a benchmark.
But if you scroll further down, you get to the memory allocation and size/FCP sections, and those demonstrate what a behemoth React is in practice. 5-10× larger than SolidJS or Svelte (compressed), and approximately 5× longer FCP scores, alongside a significantly larger runtime memory than any other option.
React is consistently more similar to a full Angular application in most of the benchmarks there than to one of the more lightweight (but equally capable) frameworks in that list. And I'm not even doing a comparison with microframeworks like Mithril or just writing the whole thing in plain JS. And given the point of this article is about shaving off moments from your FCP by delaying rendering, surely it makes sense to look at one of the most significant causes to FCP, namely bundle size?
Dan Abramov isn't "the creator of React", he just became an evangelist for react ever since he got to the team at Facebook through his work on redux. He is pushing for RSC (as that's where react's future seems to be), but what makes you think he's pushing for Vercel?
I'm not the creator of React (that would be Jordan). I've also never taken any money from Vercel and I don't care about it. I do think RSC is an interesting technology and I like writing about it while I'm on my sabbatical.
Why would I? React is just bad, the change from classes/function components to hooks abstraction was terrible but the current push to RSC made me quit 2 years ago with zero regrets. Life is great when you don't need to debug zillions of useless components re-render.
React's actual implementation is in the reconciler logic, which is then built into the platform-specific packages like ReactDOM and React Native.
So, the `react` core package is tiny because it just has a few small common methods and shims for the hooks, and all of the actual logic and bundle size are in `react-dom`.
Most of the time nobody needs this, make sure your database indexes are correct and don’t use some under powered serverless runtime to execute your code and you’ll handle more load than most people realize.
If you’re Facebook scale you have unique problems, most of us doesn’t.