02 — Next.js Foundations — JavaScript, React, and the SPA-vs-SSR Question

Every Next.js concept felt arbitrary until I walked the dependency chain underneath it. The model that clicked: Next.js is React plus opinions, and React is JavaScript — so the dependency chain runs straight through language fundamentals into component model into rendering strategy. Skip the chain and every Next.js concept feels arbitrary; walk it in order and the framework's choices start to look inevitable [1][4].

The other thing I had to nail down before anything else was the SPA vs. SSR distinction, because Next.js's whole reason for existing is letting you pick between them per route instead of once, globally [5].

JavaScript first — the non-negotiable prerequisite

Next.js is built on top of React, and React is a JavaScript library [3][4]. Trying to use Next.js without solid JavaScript fundamentals is like trying to write poetry in a language you can't order coffee in — every framework concept collides with the language gap underneath it. The roadmap is blunt about this: without a solid grasp of JavaScript fundamentals, Next.js's features and concepts won't make sense [2].

The JavaScript I actually reach for daily in Next.js:

• ES modules (import/export) — the entire module system.
• Async/await and Promises — every data fetch is async.
• Destructuring and spread — component props are built from these.
• Array methods (map, filter, reduce) — rendering lists is map.
• Closures and scope — hooks live or die on understanding these.

The way of thinking that helped: HTML is the structure of a house, CSS is the interior design, JavaScript is the electrical system that makes everything work [2]. Next.js sits on top of all three, and the electricity is the part that bites if it's shaky.

React — the component model underneath

React is a declarative, component-based library for building UIs [3]. The idea worth internalizing is that a React component is a function: data in (props, state), UI out. The library handles reconciling changes to that UI efficiently. Next.js does not replace this model — it embraces it, then adds Server Components on top so the function can run on the server instead of the browser.

The framework question is downstream of this. Building modern web apps involves managing complex UIs, handling data, and ensuring smooth UX — frameworks like React, Angular, and Next.js provide structure for these challenges so I focus on features instead of reinventing infrastructure [1]. React is the rendering core; Next.js is the structure around it.

The SPA vs. SSR decision

This is the conceptual fork that everything else in Next.js branches from [5]:

• Single-Page Application (SPA) loads one HTML page, then JavaScript updates the DOM dynamically as the user interacts — no full page reloads. Fluid UX, but the browser does the rendering work, and the initial HTML is mostly empty until JS runs.
• Server-Side Rendering (SSR) generates the HTML on the server for each request and sends a fully rendered page to the client. The user sees content immediately; search engines see real HTML.

The trade-offs are the whole story:

• SPA gives fluid navigation after the initial load, at the cost of a slow first paint and poor SEO (the crawler sees an empty shell).
• SSR gives fast first paint and good SEO, at the cost of server work per request.

The thing Next.js actually does is refuse to force this choice globally — a marketing page can be SSR for SEO, a dashboard can be SPA for interactivity, a blog can be statically generated at build time. The framework's core value proposition is the menu of rendering strategies and the per-route switch [5].

Why this matters before going further

Every later concept in Next.js — App Router, Server Components, caching, data fetching — is an elaboration of one of these two threads. The Server Components model is SSR turned into the default rendering mode. The Pages-vs-App Router split is partly about how deeply SSR is integrated. Caching is the lever that makes SSR affordable. If the SPA-vs-SSR fork is fuzzy, none of those lands cleanly.

How I use this

Before I reach for any Next.js feature, I check the prerequisites are actually in place: is the JavaScript solid? Is the React component model understood? And for each route I build, I ask the one question that drives everything else — where should this HTML be generated? Server, client, or build-time. The answer dictates the rest of the implementation.

References

[1] "Which JS framework is best?," YouTube, 2023. [Video]. Available: https://www.youtube.com/watch?v=cuHDQhDhvPE

[2] "The modern JavaScript tutorial," javascript.info, 2024. [Online]. Available: https://javascript.info/

[3] Meta Open Source, "React — The library for web and native user interfaces," react.dev, 2024. [Online]. Available: https://react.dev

[4] Vercel, "Next.js — The React framework for the web," nextjs.org, 2024. [Online]. Available: https://nextjs.org/

[5] "SSR vs. SPA showdown: choosing the right rendering approach for your web app," dev.to, 2024. [Online]. Available: https://dev.to/santhanam87/ssr-vs-spa-showdown-choosing-the-right-rendering-approach-for-your-web-app-4439

[6] Vercel, "How to build single-page applications with Next.js," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/app/guides/single-page-applications