1. React’sperformance & bundle overhead
Many argue that pushing heavy logic to the client creates slow initial renders and huge JavaScript bundles.
“Now’s a good time to figure out whether your client‑side application should have a server‑side aspect to it, to speed up initial renders.” — kylecazar
2. Server‑side rendering (SSR) is resurging
A growing number of developers champion SSR (or “islands” approaches) as a simpler, faster alternative that avoids constant client‑server round‑trips.
“SSR is objectively faster, since the client does nearly zero work other than downloading some assets.” — k33n
3. Framework performance & tree‑shaking limits
Comparisons show that newer frameworks (e.g., Qwik, Svelte) can hydrate only what’s needed, but libraries that aren’t fully tree‑shakable still pull in large portions of their code. > “Qwik is faster because it splits every single reactive element into a loader that only hydrates exactly what is needed when it is used.” — epolanski
4. Ecosystem lock‑in & inertia
The prevalence of React has created a self‑reinforcing cycle where hiring, tooling, and familiarity keep teams locked in, even when better‑performing options exist.
“I would say that 95 % of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems.” — carshodev
These four themes capture the dominant conversation about React’s complexity, the renewed interest in SSR/simpler stacks, real‑world performance trade‑offs with modern frameworks, and the social‑technical forces that sustain the React ecosystem.