--- title: "01 — Why Next.js — The Framework That Ate the React Ecosystem" uid: why-nextjs tags: ["roadmap:nextjs", "react", "frameworks", "ssr", "nextjs", "remix"] excerpt: "React is a library for rendering UI, not for shipping an app. A framework fills the gaps — routing, rendering, data fetching — and Next.js is the most complete set of those defaults." date: 2026-08-13T03:28:03+0000 source: https://www.aveshina.my.id/en/blog/why-nextjs --- "Which React framework should I use?" had a default answer I couldn't explain, so I unpacked it. The model I had to internalize before anything else stuck: **React is a library for rendering user interfaces — not for shipping an application.** Routing, data fetching, bundling, image optimization, server rendering — React ships none of that. A framework fills those gaps with opinionated defaults, and Next.js is currently the most complete set of those defaults [1][4]. ## React alone is not enough React's pitch is narrow and deliberate: a declarative, component-based library for building UIs [3]. It gives me a tree of components that turn state into DOM. Everything else — how a URL maps to a component, where data comes from before render, how the bundle is split, whether HTML is generated on a server or in the browser — React leaves open. That openness is a feature for library authors and a tax for application builders, because every team ends up assembling the same stack by hand: a router, a data layer, a build tool, a server entry point. Frontend frameworks exist to bundle that stack with sensible defaults so I can stop configuring infrastructure and start building features [1][2]. The honest framing is not "React vs. Next.js" — React is the rendering core inside Next.js. The real comparison is "assemble the stack yourself" vs. "adopt a framework that already assembled it." ## Why a framework at all The argument for frameworks is the argument against every team reinventing the same wheel: - **Routing** built in, usually file-system based. - **Data fetching** with loading and error states integrated into the render pipeline. - **Build and optimization** — code-splitting, tree-shaking, asset handling — handled by the framework's compiler. - **Rendering strategies** (SSR, SSG, CSR) selectable per route, instead of one global choice. - **Conventions** that make the codebase legible to the next developer without a tour [2]. The cost is opinion. A framework picks the patterns, and I work inside them. For most application work that trade is favorable; for a tiny widget or a highly bespoke setup, raw React plus a bundler is still legitimate. ## Why Next.js specifically Next.js is a React framework that layers extra features and optimizations on top of React for building full-stack web applications — routing, data fetching, and server-side rendering out of the box, with far less manual configuration than rolling it myself [4][5]. The features that made it the default pick for me: - **File-system routing** — directories and files become routes, no route config file to maintain. - **Hybrid rendering** — static generation, server rendering, and client rendering coexist in one app, chosen per page. - **Server Components** — React's model for rendering on the server by default, shipping zero JS for static parts of the tree. - **Built-in optimizations** — images, fonts, scripts, and code-splitting handled automatically. - **API routes** — backend endpoints live in the same codebase as the UI [5]. The community and ecosystem effect compounds all of this: Next.js is where the tutorials, the hiring demand, and the Vercel-first deployment story concentrate, which makes it the safe default even before evaluating alternatives [6]. ## Remix — the standards-first alternative The roadmap also points at **Remix**, and it sits at a meaningfully different spot on the philosophy axis [7]. Remix is a full-stack framework built on web standards — it leans hard on HTTP primitives (status codes, cache headers, progressive enhancement) and on nested routing where each route segment owns its data loader. The way of thinking is "the platform is the framework": less magic, more direct use of Request/Response. ```figure Bare React UI lib routing ✗ data ✗ build ✗ server ✗ you assemble it Next.js UI lib routing ✓ rendering ✓ data ✓ optimize ✓ opinionated defaults Remix UI lib web std ✓ nested ✓ loaders ✓ HTTP ✓ platform-first ``` My shorthand: Next.js optimizes for the widest set of defaults and the biggest ecosystem; Remix optimizes for fidelity to web standards and a tighter data-loading model. Both are excellent. I reach for Next.js because the defaults match most of the work I do and the deployment story on Vercel is friction-free. ## How I use this The decision is rarely "which framework" in the abstract — it's "do I want to assemble the stack myself or adopt opinions." For almost every application I build, adopting Next.js's opinions buys me routing, rendering flexibility, and a build pipeline I would have written anyway. The rare times I skip it are tiny isolated widgets or cases where the rest of the architecture already dictates the stack. ## References [1] S. OnDev, "Comparing the top React frameworks," dev.to, 2024. [Online]. Available: [https://dev.to/surajondev/comparing-the-top-cra-alternatives-9cg](https://dev.to/surajondev/comparing-the-top-cra-alternatives-9cg) [2] "What is the difference between a framework and a library?," YouTube, 2023. [Video]. Available: [https://www.youtube.com/watch?v=D_MO9vIRBcA](https://www.youtube.com/watch?v=D_MO9vIRBcA) [3] Meta Open Source, "React — The library for web and native user interfaces," react.dev, 2024. [Online]. Available: [https://react.dev](https://react.dev) [4] DesignRush, "10 must-know benefits of Next.js for modern web apps," 2024. [Online]. Available: [https://www.designrush.com/agency/web-development-companies/nextjs/trends/benefits-of-next-js](https://www.designrush.com/agency/web-development-companies/nextjs/trends/benefits-of-next-js) [5] Vercel, "Next.js — The React framework for the web," nextjs.org, 2024. [Online]. Available: [https://nextjs.org/](https://nextjs.org/) [6] freeCodeCamp, "Next.js for beginners," YouTube, 2024. [Video]. Available: [https://youtu.be/KjY94sAKLlw?si=orve81YcY8Fm2vDy](https://youtu.be/KjY94sAKLlw?si=orve81YcY8Fm2vDy) [7] Remix Software, "Remix — Build better websites," remix.run, 2024. [Online]. Available: [https://remix.run/](https://remix.run/) ```quiz Q: React ships with built-in routing and data fetching. True or false? - True — that's what makes it a framework - False — React is a UI library; routing and data fetching come from elsewhere correct: 1 explain: React is deliberately scoped to rendering UI. Routing, data fetching, and the build pipeline are filled in by a framework like Next.js or assembled by hand. Q: What does a frontend framework like Next.js primarily provide on top of React? - A faster React renderer - Opinionated defaults for routing, rendering, data fetching, and build tooling correct: 1 explain: Frameworks bundle the surrounding stack — routing, data, build, optimizations — with conventions so you stop assembling infrastructure and start building features. Q: Remix's distinguishing philosophy, compared to Next.js, is… - more aggressive automatic optimization - closer fidelity to web standards and HTTP primitives (status codes, cache headers, loaders) correct: 1 explain: Remix leans on web platform primitives — Request/Response, HTTP cache headers, nested route loaders — favoring standards fidelity over Next.js's wider set of opinionated defaults. Q: Why is "React vs. Next.js" a false comparison? - Next.js competes with Vue, not React - React is the rendering core inside Next.js; the real choice is assembling the stack yourself vs. adopting a framework correct: 1 explain: Next.js uses React as its UI library. The decision is whether to hand-assemble routing/data/build or accept a framework's opinions. ```