Next.js is frontend framework that does not only create some build that then gets sent to client, it also adds concepts like server side rendering and static site generation. It is simmilar to react, and like 70% of the knowledge is transferable from react and vice versa.
Routing
There were two approaches to routing in Next.js and the first one was pages router. Then they invented the App router that is the default one. Pages vs App router
- both have file based routing
- not supported | default behavior
- everything client-side |
use clientkeyword - layouts: manual | built in layout.tsx
- data fetching: getStaticProps, getServersideProps | fetch() in server, useEffect in client
- learning curve: Easy for react devs | Steeper- new concepts
Rendering models (CSR / SSR / SSG)
In Next.js, “frontend” is not only what runs in the browser, it is also where the first HTML is built.
CSR (Client-Side Rendering)
- Server mostly sends a thin HTML shell + JS bundle
- Browser downloads JS, then builds the UI and often fetches data after that
- Used for: highly interactive apps behind login, dashboards, tools
- Cost: slower first paint, SEO extra work, blank/loading state until JS runs
SSR (Server-Side Rendering)
- Server runs UI code, fetches what it needs, and returns ready HTML
- Browser shows content sooner; then JS “hydrates” so buttons/forms become interactive
- Used for: public pages, SEO, first paint, personalization that needs request-time data (cookies, auth, locale)
- Cost: more work on the server, server data fetches might block the whole load
SSG (Static Site Generation)
- HTML is built on server beforehand, then served when requested as static files
- Used for: marketing, docs, content that does not change
- Cost: stale content until revalidation
How I usually choose
- Fast first paint for public content -> SSR or SSG (App Router, or static + revalidate)
- Interactivity -> CSR
- Mixing is best: static shell + SSR for dynamic parts + client components