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.
Why Next.js
- modern paterns that allow for components to be easily reusable
- allows for clear separation in same project for frontend and backend(after initial concepts are learned)
- has somewhat standardized file paterns(some from framework itself, like layout, page, slug routes). That allows to easilz jump from one nextJs project to other because you know where to look
- has great performance on bad networks with server side rendering and static site generation because there is almost only the html that is displayed
- uses Typescript, that is IMO nice because of the build in functions so you dont have to create helper methods that much and is easy to read after you set some rules
- you can use NPM packages that have something for every common usecase and some are specificaly for React/Next.js
- it is standard to use Next.js for web apps so finding other developers is easy
- since it is that popular there is a lot of examples from other devs
Routing
There were two approaches to routing in Next.js and the first one was pages router(legacy now). Then they invented the App router that is the default now and all showcases are with app router concepts.
Pages router | 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