Next.js in 100 Seconds // Plus Full Beginner's Tutorial

Next.js is positioned as a React framework that fixes two major weaknesses of client-side rendering—poor search/social indexing and slower first content—by letting pages arrive as fully rendered HTML from the server, then switching to interactive React in the browser. That “best of both worlds” approach matters because search engines and link-bot crawlers depend on HTML content being present immediately, while users still need fast, interactive behavior once the page loads.

In a Next.js project, routing is driven by the filesystem. A top-level `pages` directory maps directly to URLs: each JavaScript file exports a default React component that represents a route. For example, creating `pages/hello.js` makes `/hello` work automatically. Navigation is handled by Next’s router, so moving between routes behaves like a typical React app without manual wiring.

Dynamic routing extends this model. By creating a folder like `pages/cars` and adding an `index.js` for the list view, Next can render nested routes. Individual car pages use bracket syntax—`[id].js`—so `/cars/tesla` or `/cars/whatever` loads the same component with different URL parameters. Inside that dynamic page, the `useRouter` hook reads query parameters (such as `id`) and renders them into the UI.

Next also includes an `api` directory for server-only endpoints. Code placed there runs on the backend and doesn’t inflate the client-side JavaScript bundle, making it useful for server work or for exposing APIs.

The core differentiator is data fetching and server-rendering strategies. Next supports three approaches from the same codebase: static generation (pre-rendering), server-side rendering (SSR), and incremental static regeneration (ISR). Static generation uses `getStaticProps` to fetch data at build time, then bakes the resulting HTML into files that can be cached aggressively via a CDN—ideal for blogs or content that changes infrequently. The trade-off is staleness: updates require rebuilding and redeploying.

For dynamic routes under static generation, Next needs to know which pages to pre-render ahead of time. That’s handled by `getStaticPaths`, which returns a list of all route parameters (e.g., `tesla`, `ford`, `lambo`) and can include fallback behavior. With the fetched data, pages can render SEO-critical elements like titles and social meta tags using Next’s `Head` component.

When data changes constantly, SSR uses `getServerSideProps`, which runs on every request so the server fetches the latest data each time. SSR is more accurate but less efficient because it requires ongoing server computation rather than relying on globally cached static assets—an approach likened to high-churn marketplaces.

Finally, ISR offers a middle path: adding a `revalidate` option to `getStaticProps` allows Next to regenerate pages when requests arrive after a specified interval, reducing staleness without the full cost of SSR. The result is a flexible rendering toolkit that can be applied per page rather than forcing a single strategy across an entire app.