Argues that React's 'correct' usage now demands Next.js, Server Components, and the '"use client"' directive — a programming model that is neither pure JavaScript nor a clean framework. The library that won by being 'just JavaScript' has become an opaque build-time graph that developers can no longer easily inspect or reason about.
Notes that React's own docs no longer recommend Create React App, Vite-with-React, or any plain SPA setup — the 'start a new React project' page funnels developers to Next.js, Remix, or Expo. This represents a structural shift where the React team has ceded the default developer experience to a single commercial vendor.
Points out that React shipped Server Components in 2023 but the broader ecosystem — Vite, Remix, TanStack — is still trying to catch up to a specification that Vercel effectively controls. The result is fragmentation: a feature blessed by the core team that only one framework actually implements well.
A nine-year React veteran admits they cannot explain what a Server Component is to a junior developer without drawing a diagram. The complaint signals that React's mental model has grown beyond what a working professional can convey through normal mentorship — a leading indicator that previously preceded the decline of jQuery and Angular 1.
Argues that React's twelve-year reign is now longer than any modern frontend library, and the structural cracks visible in 2026 resemble those that doomed jQuery and Angular 1 before their displacement. Frontend dominance erodes gradually until a tipping point, and the loud agreement from React-in-bio developers on HN suggests that point may be approaching.
A post titled "Does Anybody Actually Like React?" — hosted at the deliberately on-the-nose domain `jsx.lol` — climbed to 147 points on Hacker News this week. That's not a viral hit by HN standards, but the comment section is what makes it notable: the dissent is mild, the agreement is loud, and a striking number of the loudest agree-ers list React in their bios.
The author's argument is short and unsentimental. React, they write, has drifted from a focused view library into a sprawling meta-framework whose "correct" usage now requires Next.js, an understanding of Server Components, a mental model for the `"use client"` directive, and a willingness to accept that your component might run on the server, the client, or both depending on a build-time graph you can't easily inspect. The library that won the frontend by being "just JavaScript" now ships a programming model that isn't quite JavaScript and isn't quite a framework.
The HN thread piles on with specifics. One commenter notes that the React docs no longer recommend Create React App, Vite-with-React, or any plain SPA setup — the official "start a new React project" page funnels you to Next.js, Remix, or Expo. Another points out that the React team shipped Server Components in 2023 and the broader ecosystem (Vite, Remix, TanStack) is still trying to catch up to a spec that Vercel effectively owns. A third, with the tartness HN does well: "I've been writing React for nine years and I cannot explain to a junior what a Server Component *is* without drawing a diagram."
Frontend frameworks lose their grip slowly and then all at once. jQuery was dominant for a decade before Angular ate its lunch; Angular 1 was the default until React's 2015–2017 run displaced it. React has now held the throne for roughly twelve years — longer than any frontend library in the modern era — and the cracks showing up in 2026 look structurally similar to the ones that doomed its predecessors.
The technical case against React in 2026 is no longer about bundle size or rendering performance, where it has been beaten for years. SolidJS posts a 7KB runtime with fine-grained reactivity that doesn't require `useMemo`, `useCallback`, or a mental model of referential equality. Svelte 5's runes ship reactivity at the language level — no virtual DOM, no reconciler, no `key` prop foot-guns. Vue 3 + Nuxt offers most of what Next.js offers with a markedly gentler learning curve. Qwik's resumability sidesteps hydration entirely. None of these are research projects; all of them have production users at scale.
What React still has, and what the jsx.lol post implicitly attacks, is the meta-framework lock-in. If you adopt React in 2026, you are not really adopting React — you are adopting Vercel's opinionated stack, with its build-time magic, its server/client boundary rules, and its caching defaults that have shipped breaking changes twice in eighteen months. The Next.js 15 caching reversal (where `fetch` calls are no longer cached by default, reversing the Next.js 13 decision) is the kind of churn that makes seasoned engineers reach for stabler options.
The community reaction is also revealing in what it *doesn't* say. There are no top-level comments defending Server Components as a great DX win. The pro-React arguments are all economic: "the hiring pool is bigger," "every component library targets React first," "my team already knows it." Those are real arguments — they're how Java won the 2000s and how PHP outlived its critics — but they're not technical arguments. When the defense of a technology shifts entirely to ecosystem and hiring, the technology has already lost the argument on merit; the only question is how long the inertia lasts.
The Vercel-ification of React is the deeper story here. The React core team has substantial overlap with Vercel's payroll, and the design decisions of the last three years — Server Components, the App Router pattern, the Server Actions API — make the most sense when you assume a Vercel-shaped deployment target. Teams running React on Cloudflare Workers, on their own Kubernetes, or in a static-export configuration have spent the last two years discovering that the happy path is increasingly narrow.
If you're starting a new project in 2026, the calculus has genuinely changed. For a content site or marketing surface, Astro with islands of whatever framework you like (including React) gives you better Core Web Vitals than any all-React setup and lets you defer the framework decision per-component. For a dashboard or internal tool, SolidStart or SvelteKit will get you to production faster and with a smaller maintenance surface than Next.js, especially if your team doesn't have a dedicated frontend platform engineer. For a large product with an existing React team, the honest answer is still React — but pin yourself to Vite + React Router + TanStack Query and ignore the App Router until the dust settles.
If you're maintaining an existing React codebase, the read here is: don't migrate to the App Router yet. Two and a half years in, the migration stories on HN are still dominated by edge cases, hydration mismatches, and caching surprises. The Pages Router is in maintenance mode but it works, and "works" is a feature.
If you're hiring, the framework agnosticism that was a red flag in 2019 ("why doesn't this senior know React?") is becoming a green flag in 2026. Engineers who've shipped production Svelte, Solid, or Vue have usually done so deliberately, against the grain, and tend to have stronger fundamentals as a result.
React isn't going anywhere in the next three years — there's too much production code, too many job listings, and too much component-library inertia for a sudden collapse. But the era when "we picked React" was a defensible default with no follow-up questions is ending. The next default won't be one framework; it'll be a meta-decision about whether you want a framework at all, or just a renderer plus a router plus a data layer you control. A 147-point HN thread doesn't move markets, but it's a useful tell: when the people shipping the technology start agreeing with the title "does anybody actually like this," the answer is already in motion.
React is fine. It's main problem is a lack of guardrails to stop bad engineering cultures from doing stupid things.
Of course people do. No one is forced to use React or any other web framework unlike how they are practically forced to use JavaScript, and yet React wins. This should be enough evidence that people like it enough, at least more than most other frameworks out there.It is also somewhat ironic that un
I like React. And I have seriously tried the HTMX/Hotwire camp.I wanted to make a back button use browser APIs to go back if the coming from the inbox, just link to the inbox otherwise to preserve scrolling. I had to wire the actions from the html to call the function that goes back, then in my
After spending so long writing React code, I'm now working on a large Vue project at work. Everyone used to say Vue was the easier of the two, the more approachable option — but I'm starting to see it differently. React, in its elegance, gives you components that are essentially just funct
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense:React is the worst JS framework except for all the others we've tried.I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build