|
|
|
|
|
|
by SeanAnderson
239 days ago
|
|
|
I feel like the introduction of React Compiler was a pretty big change, too? The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower. To be fair, I haven't written in React for a few years now. I reached for Svelte with the last two apps I built after using React professionally for 4 years. I was expecting there to be a learning curve and there just... wasn't? It was staggering how little I had to think about. Even something as small as not having to write in JSX (however normalized I was to writing in it) really felt meaningful once I took a step back and saw the forest for the trees. I dunno. I just remember being on the interview circuit and asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used, how something like console.log would fair in relation to them, when to include/exclude arguments from memoization arrays, etc.. and it was pretty easy to trip a lot of people up. I think the introduction of the compiler is an attempt to mitigate a lot of those pains, but newer frameworks designed with those headaches in mind from the start rather than mitigating much later and you can feel it. |
|
|
React 19 required almost no code changes in my multiple production apps so unless I missed something, I would say the API surface was virtually unchanged by it
> The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.
What are you talking about? Next.js != React, that's your own fault if you bought into their marketing. TanStack / React looks to be a slightly larger bundle size but I'm seeing FCP differences from 35ms to 43ms (React being 43ms), how is that orders of magnitude slower?
Bad faith or bad reading, I can't help you either way here
> asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used
What are you even trying to say? Are you implying that other web frameworks don't come with any state management, or that they are reactive, or that you don't need the concepts from React in them?
"People got confused sometimes" isn't really a defense when the alternative is a framework you only ever use on solo greenfield projects that you've never talked to another engineer about their core concepts.
Seriously, you are just peddling groupthink, there isn't a single legit criticism of React.
Next.js, on the flip side, we should all go off on those clowns, but I wouldn't touch that with a 10 foot pole so I don't see how it's even relevant.