You've heard the names. Everyone's using them. But what are they, really — and why does the platform you deploy them on suddenly matter so much?
React is a JavaScript library Facebook open-sourced in 2013 for building user interfaces from reusable components. It changed the grammar of frontend development and now runs on 82% of frontend developers' projects.
Next.js is the full-stack framework Vercel built on top of React — adding routing, server rendering, API routes, image optimization, and the deployment pipeline most React developers now rely on. It's the dominant way to ship React apps in production.
Together they power a huge slice of the modern web. But the platform where you deploy your Next.js app has become a genuine battleground: Cloudflare is making aggressive technical and strategic moves to decouple Next.js from Vercel's infrastructure — and the costs, tradeoffs, and drama are real.
By the end of this article you'll understand what they are, how dominant they are, who's challenging them, and exactly what Cloudflare's strategy is to pry Next.js developers away from Vercel.
To understand why React exists, you need to understand what web development looked like before it — and why that model broke down as applications got more ambitious.
The early web had a beautifully simple architecture. You typed a URL. A server generated a page and sent it to your browser. Your browser displayed it. You clicked a link, the cycle repeated. Every action was a round trip: request, response, full page reload.
This was fine for reading Wikipedia. It was a disaster for building Gmail.
Think about what Gmail needs to do. Load new emails without refreshing the page. Show an unread count that updates in real time. Let you compose a message in a side panel while still browsing your inbox. Star a thread without losing your scroll position. Every one of those things, in the traditional round-trip model, would require a full page reload. The experience would feel like a 1998 website, because architecturally, it would be one.
Developers patched this problem with AJAX (Asynchronous JavaScript and XML), a set of techniques that let the browser fetch data from a server without reloading the page. Meanwhile, JavaScript could already reach into the page and change things directly — update a headline, swap an image, hide a button — by talking to the browser's internal representation of the page: the DOM (Document Object Model). When your HTML loads, the browser parses it into a tree of objects — every heading, paragraph, and div becomes a node. JavaScript can find those nodes and modify them. That's DOM manipulation. jQuery, released in 2006, made both AJAX and DOM manipulation dramatically easier and became the tool virtually everyone used. At its peak, jQuery ran on 70–80% of all websites.
But jQuery was structural duct tape. It made individual DOM updates easier, but it didn't give you a coherent model for managing state — for keeping track of what data your app holds and keeping the UI in sync with it. As applications grew more complex, you had to manually track every state change, manually find the right DOM elements, manually update them. Add enough features and this became genuinely unmaintainable.
The problem React solved wasn't "making web pages look nice." It was managing complexity in UIs that have lots of moving parts. The bigger and more interactive an application, the more this problem hurts — and by 2012, the biggest applications were hurting badly.
Facebook's frontend codebase in 2012 was a perfect storm of this complexity. The News Feed, Chat, Notifications, and Ads systems all shared a messy jQuery codebase that nobody fully understood. Fix a bug in one place, break something else. Ship a feature to the Ads system, watch the Chat counter glitch. The maintenance cost was spiralling. And the Ads system was where Facebook made its money.
That context matters. React didn't emerge from an academic computer science lab. It was built by engineers with a production problem that cost real money. That shapes what it prioritises.
A JavaScript library for building user interfaces — created by Facebook in 2013, open-sourced the same year, and now the dominant tool for building interactive web UIs.
Jordan Walke, a software engineer at Facebook, started experimenting with a different approach to UI development around 2011–2012. His prototype was called FaxJS. The core idea: instead of imperatively telling the browser "find this element and change this text," you describe what the UI should look like given the current data — and let the library figure out how to get the browser there.
It became React. Facebook open-sourced it at JSConf US in May 2013. The reception was mixed — some developers found the JSX syntax (HTML-like code written inside JavaScript files) alien and uncomfortable. Others immediately saw that the underlying model was a genuine improvement.
The core React model has two pillars:
React encourages you to break your UI into components — self-contained, reusable pieces that manage their own appearance and behaviour. A Button component. A UserCard component. A SearchBar component. Each one knows what it looks like and how it responds to user input.
The LEGO analogy is genuinely apt. Individual LEGO bricks are simple and self-contained. You compose them together to build complex structures. If a brick breaks, you replace that brick — not the whole model. React components work the same way. A bug in your CommentThread component doesn't affect your ProfileHeader component. The pieces stay clean.
Think of your UI as a function: UI = f(data). When the data changes, React re-runs the function and figures out the minimum updates needed. You describe what you want; React handles how to get there.
This distinction trips people up. React handles one thing: building and updating user interfaces. It has nothing to say about:
How you navigate between pages. How you fetch data from an API. How you handle authentication. How you structure your backend. Where you deploy your code. You wire all of that up yourself — or you use something built on top of React that makes those decisions for you.
That "something built on top of React" is what the meta-framework era is about. And Next.js is the one that won.
The fact that React is a library — not a full framework — is both its greatest strength and the source of most "React fatigue." Freedom means choice, and choice means decisions. The ecosystem has evolved to reduce that decision load, but understanding that React itself is intentionally minimal helps you understand why so many companion tools exist.
"Reactive" is one of those words the tech world uses constantly and defines inconsistently. Here's the clearest version — and why it was a genuine breakthrough.
Reactivity means your UI automatically updates when your data changes — without you manually telling it to.
The spreadsheet analogy nails it. In Excel, if cell B1 contains the formula =A1 * 2, and you change the value in A1, B1 updates immediately. You don't click a "refresh B1" button. The spreadsheet reacts to the change and propagates it automatically, across every cell that depends on it.
React's reactivity works the same way. You describe how your UI depends on your data. When data changes, React handles the update. You don't manually find DOM elements and change their text — you just change the data, and the UI follows.
The mechanism React uses to do this efficiently is called the Virtual DOM.
Your browser represents a webpage as a tree of objects called the DOM (Document Object Model). Updating the DOM is relatively expensive. Before React, jQuery and similar tools made DOM manipulation easier, but you were still directly prodding the browser's internal representation of the page every time something changed.
React introduced a smarter intermediary. It keeps a lightweight JavaScript copy of the DOM tree in memory — the Virtual DOM. When your data changes, React updates this in-memory copy first. Then it compares the new virtual tree to the previous version, calculates the minimum set of changes needed (this process is called "diffing"), and applies only those changes to the real browser DOM.
Imagine a film editor who doesn't re-shoot an entire movie just because one line of dialogue changed. They cut exactly the frames that need replacing. React does the same thing — surgically updating only the parts of the page that actually changed, rather than rebuilding everything.
This was revolutionary in 2013. Developers who had spent years manually coordinating DOM updates suddenly had a system that handled that coordination automatically, efficiently, and predictably.
"Reactivity" is now a standard expectation across all modern web frameworks. Vue, Svelte, Solid, and Angular each have their own implementation. Svelte compiles reactivity away at build time — there's no Virtual DOM overhead at runtime, because the reactive updates are baked directly into the generated JavaScript. Solid.js takes fine-grained reactivity further, updating exactly the affected DOM nodes without any diffing step at all.
React's model wasn't the last word. But it set the conceptual vocabulary that every framework since has had to respond to.
The Virtual DOM is often described as React's "secret sauce for performance." That's a little misleading. The Virtual DOM isn't free — it has overhead. React's performance advantage comes from doing fewer unnecessary updates, not from the Virtual DOM itself being faster than direct DOM manipulation. For extremely performance-critical UIs, frameworks like Svelte and Solid that avoid the Virtual DOM entirely can have an edge.
If React is the engine, Next.js is the car. Everything React deliberately leaves out — routing, server rendering, API routes, image optimisation, deployment — Next.js adds back in.
Next.js was created by Vercel (then called ZEIT) and first released in 2016. Vercel's founder Guillermo Rauch, already well-known for building Socket.io, saw a gap: React was powerful, but building a production-ready React app required assembling a dozen separate tools and configuring them all to work together. Next.js packaged the most common decisions into a coherent whole.
The elevator pitch: Next.js is what you use when you want to ship a real React application, not just a demo. It handles the infrastructure, so you can focus on the product.
In Next.js, your folder structure is your URL structure. Put a file at app/about/page.tsx and you get a page at /about. Create app/blog/[slug]/page.tsx and every blog post at /blog/anything maps to that file. No routing library to install, no config to write. The folder hierarchy is the router.
This is where Next.js gets substantive — and where most new developers first feel the complexity. Next.js supports three rendering strategies, and you can mix them in the same project:
The server sends a mostly-empty HTML shell. JavaScript runs in the browser and builds the UI. React alone does this. Fast to start, but the user sees nothing until JS loads. Poor SEO.
The server generates full HTML for every request. The user sees content immediately. React then "hydrates" it — attaches interactive behaviour. Better SEO. More server cost per request.
Pages are generated once at build time and served as static files. Blazingly fast. Ideal for content that doesn't change per-user: blog posts, docs, marketing pages. Technoobtopia uses this approach.
Next.js lets you put backend logic in the same project as your frontend. A file at app/api/contact/route.ts becomes a serverless API endpoint. Your frontend and backend share the same codebase, the same types, and deploy together as one unit. For many applications, this eliminates the need for a separate backend service entirely.
In 2023, Next.js 13 introduced the App Router — a significant architectural change. It's built around React Server Components (RSC): components that run on the server and send only the rendered HTML to the browser, reducing JavaScript bundle size. Powerful, but it changed the mental model considerably from older Next.js patterns. Many tutorials and Stack Overflow answers you'll encounter are written for the older Pages Router — it's worth knowing which one you're reading about.
Next.js is MIT-licensed — free, open source, deployable anywhere. But Vercel, who created it, offers the platform where it runs most completely. Certain features — image optimization, ISR (Incremental Static Regeneration), edge middleware — have historically been easier or worked better on Vercel's infrastructure. This is not accidental. If you use Next.js, Vercel is the path of least resistance. That's a business strategy as much as a technical one.
"Popular" is vague. Let's be specific. Here's what the data actually says.
These numbers aren't close. Vue.js — React's most credible competitor in raw developer usage — comes in at 51% in the State of JS survey, but that's on a smaller respondent base. Among the full developer population, React's lead is substantial.
Next.js's position within the React ecosystem is similarly entrenched. It's used by 16.67% of all developers and is the only framework with full production-ready support for React Server Components. When developers reach for a React meta-framework, Next.js is the default choice for the overwhelming majority.
"Learning React in 2026 is not a niche career choice. It is a table-stakes skill for frontend web development."
The satisfaction picture is more nuanced. Svelte and Vue consistently rank higher than React in developer satisfaction surveys — developers who use them tend to love them more. React's pain points are well-documented: complexity overhead, choice fatigue around the surrounding ecosystem, and the cognitive load of the App Router's new mental model.
But satisfaction and usage are different measures. React's dominance is self-reinforcing: more React jobs mean more React developers, which means more React libraries, which means more teams defaulting to React. The momentum is significant.
React's dominance doesn't mean the competition is irrelevant. These challengers are real, well-built, and used by excellent teams.
There are two tiers to this: alternatives to React as a UI library, and alternatives to Next.js as a meta-framework.
The most credible alternative in raw adoption. Gentler learning curve than React, similar component model, excellent documentation. Particularly strong in Asia and Europe. Nuxt is its Next.js equivalent and has matured into a first-class full-stack framework.
Compiles your components to efficient vanilla JavaScript at build time — no Virtual DOM, no runtime overhead. The result: smaller bundles, snappier performance, and a syntax that many developers find genuinely pleasant. Tops satisfaction rankings in State of JS. SvelteKit is its full-stack counterpart.
React if it were designed in 2020. Fine-grained reactivity that targets exactly the DOM nodes that need updating — no diffing, no Virtual DOM. JSX syntax will feel familiar to React developers. Excellent performance. Still niche, but developers who use it tend to be deeply satisfied.
Google's full-stack framework. More opinionated than React — it has opinions about routing, state management, forms, and almost everything else. Losing mindshare to React but remains huge in enterprise, government systems, and large organisations that built on it before React won. Angular developers are well-employed.
Takes a different bet entirely: for content-heavy sites, you shouldn't ship JavaScript unless you genuinely need it. Generates HTML at build time, ships zero JS by default. Interactive "islands" can use React, Vue, or Svelte. The best tool for content-first sites — and the framework powering Technoobtopia.
Now merged into React Router. Focuses on web platform primitives and progressive enhancement — your app works even if JavaScript fails. Strong opinions about data loading patterns. A thoughtful alternative for teams who find Next.js's complexity taxing.
Vue's equivalent of Next.js — file-based routing, SSR, SSG, API routes, the full package. If your team is already on Vue, Nuxt is the natural full-stack choice and is well-maintained and production-ready.
Full-stack React built around TanStack Router. Type-safe, file-based routing with server functions. Still newer to the scene, but TanStack has a strong track record (TanStack Query/Table are widely used). Worth watching for teams that want React without Next.js's opinions.
Cloudflare has a problem. Millions of developers built Next.js apps. Next.js runs best on Vercel. Their answer: don't fight Next.js — make Next.js run on Cloudflare instead.
This is a smarter move than it might initially sound. Asking developers to abandon a tool they've invested in is a hard sell. Removing the friction that keeps them tied to one deployment platform is a much easier pitch: "Keep your codebase. Keep Next.js. Just pay less."
Cloudflare's official approach to running Next.js is through the @opennextjs/cloudflare adapter — an open source project that adapts Next.js builds to run on Cloudflare Workers. This is a non-trivial engineering challenge: Next.js doesn't expose clean deployment interfaces, so building an adapter means working around build outputs and adapting them to a different runtime environment.
Cloudflare's original @cloudflare/next-on-pages package — which you'll still see referenced in older tutorials — is now deprecated. The newer OpenNext-based adapter is the current recommendation, and it's a meaningful upgrade: it supports the full Node.js runtime (not just Cloudflare's edge runtime), covers most App Router features including ISR and image optimization, and tracks Next.js versions more closely.
It's not feature-complete parity with Vercel. Some Next.js capabilities that depend on Vercel-specific infrastructure still have gaps. But the gaps are narrowing fast, and for most applications, the overlap is substantial.
Vercel's pricing is per-function-invocation, per-bandwidth-byte, per-team-seat. A Next.js app that goes viral can generate a $1,000–$10,000 Vercel bill in hours — there are no hard spending caps on Pro plans, only billing alerts. Cloudflare Workers' pricing model is fundamentally different: a generous free tier, predictable paid tiers, and zero egress fees on storage. For apps at scale, the difference can be dramatic.
In early 2026, Cloudflare went further. A single engineer used an AI coding agent called OpenCode, the Claude Opus 4.5 model, and roughly $1,100 in API costs to fork Next.js and replace Turbopack — its proprietary Rust-based build system — with Vite, the open, broadly-supported build tool used across the JavaScript ecosystem.
The result was vinext. The goal wasn't speed benchmarks — it was portability. Turbopack produces opaque build artifacts that don't map cleanly to open deployment standards. Vite's build outputs do. If vinext worked, a Next.js app's build output would be standardised enough to deploy equally well on any platform — not just Vercel.
Vercel CEO Guillermo Rauch responded on X, framing this as "vibe coding" — AI-assisted development producing code that appeared to work but hadn't been audited for security or production correctness. He had a point about the fine print: Cloudflare's launch post called the project experimental while the headline implied production readiness. The dual messaging was legitimately confusing.
"The cost of rewriting a competitor's software stack had just dropped by a factor of 100. That changes the economics of every platform war in tech."
But the subtext of Rauch's response was hard to miss: Vercel was threatened. Not by vinext as a finished product — but by the precedent. One engineer, one week, $1,100. This is now what software competition looks like in the AI era.
The pattern extends beyond vinext. When Vercel Labs published just-bash — a TypeScript reimplementation of a bash-like shell designed for AI agents — Cloudflare forked it under the Apache-2.0 license and published it as @cloudflare/shell. The fork was legal (Apache-2.0 explicitly permits this). The optics prompted a loud community conversation about vendor namespacing of small maintainer projects.
We covered the full story — and the drama — in the Cloudflare vs. Vercel editorial. The pattern is consistent: Cloudflare isn't trying to kill Next.js. They're trying to decouple it from Vercel. That's a smarter, longer game.
Honest answers. No hedging, no sponsor-friendly qualifications.
Start with React + Vite. Build a few components, a simple app with routing, something that fetches from an API. Don't add Next.js until you understand what React itself is doing underneath. Next.js makes many architectural decisions on your behalf — if you don't understand those decisions, you won't know when to override them.
Use Astro. Genuinely. You don't need React's component model for pages that are mostly text and images. Astro ships faster pages with less JavaScript, makes content-first workflows pleasant, and supports React components in the places where you actually need interactivity. We'd say this even if this site weren't built on it.
Next.js on Vercel is still the benchmark. The developer experience is excellent, the documentation is thorough, the framework-to-platform integration is seamless. Pricing is manageable if your traffic is moderate and predictable. Watch the billing dashboard if you expect traffic spikes — there are no hard cost caps on most plans.
Next.js on Cloudflare via the OpenNext adapter is increasingly viable. The feature gaps with Vercel are narrowing. Cloudflare's pricing is more predictable, the free tier is genuinely generous, and you get a 330+ city global network as your infrastructure foundation.
Look at Svelte/SvelteKit or Solid.js. Both offer real performance advantages over React's Virtual DOM model. Svelte especially has strong developer satisfaction numbers. The tradeoff: smaller ecosystems, fewer hiring options, less community content.
React and Next.js won. Not "are leading" — won, past tense. Learning them is close to mandatory for frontend web development work in 2026. Vue and Svelte are excellent and the developers who use them are excellent. But if you're starting from zero and career outcomes matter, React is the first thing to learn. The platform where you deploy it is the variable — and that's what the current war is about.
The concepts from this article, distilled.
Natural T3 continuations of this topic — not live yet, but they're coming.
What RSCs change about data fetching, bundle size, and where your code runs — and when NOT to use them.
Vite, esbuild, webpack, Rollup: what they actually do, why Vite won the DX war, and what it means for your project setup.
Types, inference, generics — why every major framework standardized on it and how to read unfamiliar TS without freezing.
When and why teams reach for monorepos, how workspace packages work, and what task graphs actually do under the hood.