Rendering and architecture

With CSR the first HTML is little more than a script tag and an empty container. The browser downloads the JavaScript bundle, runs it, fetches data from an API and only then draws the page. After that first load, moving between screens is quick, because only data travels, not whole pages.

The costs come at the start: visitors see a blank screen or a spinner until the bundle has loaded, slow phones feel it most, and search engines and link previews may see little content. Google can run JavaScript, but most social media crawlers cannot. CSR is the default for single-page apps built with Vite, and frameworks let individual routes opt into it.

When a request arrives, the server fetches the data, renders the components to HTML and sends a complete page. The browser can show it immediately; then the JavaScript loads and hydrates the page to make buttons and forms work. Because the page is built per request, it can be personalised, for example to show the signed-in user's basket.

This is how PHP, Rails and Django sites have always worked, and frameworks such as Next.js, Nuxt, SvelteKit and React Router bring it to component-based apps. Streaming lets the server send the page in pieces, so slow parts do not hold up the rest. The trade-off is a server doing work on every request, which costs money and adds delay when it sits far from the visitor or the data.

At build time the framework fetches the data (from Markdown files, a CMS or an API), renders every page and writes out HTML, CSS and JavaScript files. Those files go to a CDN, which serves them from a location near each visitor with no server work per request. Astro, Next.js, Nuxt, SvelteKit, Hugo and Eleventy can all do this.

The catch is freshness: a change goes live only after a rebuild, and sites with tens of thousands of pages can take a long time to build. Incremental static regeneration and on-demand revalidation solve much of that. Interactive parts such as search or a basket still work through JavaScript and APIs.

A page is generated once and cached like a static file. With a revalidate time of, say, 60 seconds, the first visitor after that minute still gets the cached page instantly while the server rebuilds it in the background, and the next visitor sees the fresh version. On-demand revalidation lets a CMS or a webhook refresh one page the moment its content changes.

Next.js introduced the term, and similar features exist in Nuxt route rules, SvelteKit on Vercel and plain CDN cache headers (stale-while-revalidate). Pages not built ahead of time can be generated on their first request. It needs a host that supports it: Vercel and Netlify handle it automatically, while self-hosting on several servers needs a shared cache.

Server rendering and static generation send finished HTML, but it does nothing until the framework loads, rebuilds its component tree in memory, matches it against the existing HTML and attaches event handlers. Until hydration finishes, a page can look ready but ignore taps. If the server and browser render different output (a date or a random value, for example), a hydration mismatch warning appears and parts of the page may re-render.

Because hydrating a whole page is costly, newer approaches do less of it: islands (Astro) hydrate only the interactive components, selective hydration (React) handles first what the user touches, Server Components never hydrate at all, and resumability (Qwik) skips the step entirely.

A Server Component can be async, read a database or call an API directly, and render the result. Its code never reaches the browser; React sends a compact description of the output, which the browser merges into the page. Components that need state or event handlers are marked 'use client' and hydrate as usual, and the two kinds can be nested inside each other.

Server Functions, marked 'use server', let browser code call server logic, such as saving a form, without writing an API route. Server Components became stable in React 19. The App Router in Next.js is the most widely used implementation, and frameworks such as React Router and Waku support them to varying degrees.

Code that the browser can reach on the server is an attack surface: in December 2025 a critical flaw known as React2Shell in the protocol behind Server Components allowed remote code execution, and fixing it meant upgrading React and Next.js straight away.

In a SPA the browser downloads the app once. Clicking a link does not load a new document; a client-side router changes the URL with the History API and redraws only the parts that differ, fetching data from an API as needed. Gmail and most admin dashboards work this way.

SPAs usually render on the client, which brings the CSR trade-offs: a slower first load and weaker SEO unless a framework adds server rendering. They also have to handle things browsers give multi-page sites for free, such as scroll position, focus after navigation and announcing page changes to screen readers.

Each URL is its own HTML document, rendered on the server or at build time. Clicking a link makes the browser fetch and show the next page, with history, scrolling and accessibility handled by the browser itself. WordPress, Laravel and Django sites, and most static sites, are MPAs.

The old downsides, a flash between pages and lost state, have shrunk: browsers cache pages well, cross-document view transitions can animate between pages in Chrome, Edge and Safari, and tools such as htmx or small islands of JavaScript add interactivity where it is needed. Frameworks such as Astro build MPAs on purpose.

A PWA is a normal website plus two things: a web app manifest (a JSON file with the name, icons and colours) and a service worker that caches files and data so pages load without a connection. Served over HTTPS, it can be installed from the browser to the home screen or desktop, opens in its own window and, on most platforms, can receive push notifications.

Support varies by platform. Chrome and Edge on Android and desktop offer an install prompt; iPhones and iPads install through Share, then Add to Home Screen, and have supported web push for installed apps since iOS 16.4. A PWA can also be listed on Google Play as a Trusted Web Activity, or in the Microsoft Store. It cannot reach every device feature a native app can, such as some Bluetooth, background and widget abilities.

A page registers a service worker file, which the browser installs and keeps separately from any open tab. It can intercept every network request from the site and decide whether to answer from the Cache Storage API, go to the network, or both, which is how offline pages and instant repeat visits work. It also receives push notifications and background sync events while the site is closed.

Service workers run only over HTTPS (or on localhost) and cannot touch the page's DOM. Caching strategies are easy to get wrong, and a faulty worker can keep serving stale files for a long time, so most teams use Workbox or a framework plugin. Browser extensions built on Manifest V3 also use a service worker as their background script.

The name stood for JavaScript, APIs and Markup. Pages are generated ahead of time (SSG) and deployed to a CDN, and anything dynamic, such as forms, search, payments or comments, is handled by JavaScript calling APIs or serverless functions. Netlify popularised the term in the late 2010s, alongside static site generators and headless CMSs.

The ideas spread, but the label faded. Modern frameworks mix static pages, server rendering and edge functions route by route, so few projects describe themselves as Jamstack any more. The core advice still holds: pre-render what you can, serve it from a CDN, and keep servers for the parts that need them.

In a monolith, the web pages, API, background jobs and business logic live in one project and ship together. Calls between features are ordinary function calls, a single database transaction can cover several features, and there is one thing to build, test, deploy and monitor. Rails, Laravel and Django apps, and a Next.js app with its API routes, are typical monoliths.

Problems appear with size: a big codebase gets slow to build and risky to change, and one busy feature cannot be scaled on its own. A modular monolith, with clear boundaries between features inside the one codebase, keeps most of the simplicity while leaving a later split possible. Some well-known teams have moved back from microservices to a monolith after finding the overhead too high.

Each service, such as accounts, payments, search or notifications, has its own codebase, its own database and its own deployments, and talks to the others through APIs (REST, gRPC) or message queues. Teams can pick the language that suits each service, release on their own schedule and scale only the parts under load, usually with containers on Kubernetes or on serverless platforms.

The price is complexity. Network calls fail and add delay, data spread across many databases is hard to keep consistent, and following one request through many services needs proper monitoring and tracing. Microservices mostly solve an organisational problem, many teams working on one product, which is why they tend to pay off at large scale rather than at the start.

In MVC, a controller receives a request or input, works with the model (data and business rules) and picks a view to render. Web frameworks such as Laravel, Rails, Django (which calls it MTV), ASP.NET MVC and Spring MVC are built around it. In MVVM, a view model holds a screen's state and actions, and the view binds to it and updates automatically when it changes.

MVVM came from Microsoft's desktop frameworks and is now the usual pattern for Android apps built with Jetpack Compose and ViewModel, and common in SwiftUI apps. Component frameworks such as React blur the lines, but the core idea, keeping business logic out of the interface code, still makes an app easier to test and change.

Most requests succeed, so instead of showing a spinner the app updates the screen immediately and sends the request in the background. If the server rejects it, the app rolls back to the previous state and tells the user. The result feels instant even on slow connections.

React's useOptimistic hook, TanStack Query's onMutate callback and similar tools in other frameworks handle the bookkeeping. It suits likes, list edits, reordering and chat messages; it does not suit payments, bookings or anything where showing success too early would mislead.

A local-first app reads and writes a database on the device, such as SQLite or IndexedDB, so every action is immediate and nothing waits on the network. A sync engine sends changes to a server or to other devices whenever a connection exists. When two people edit the same thing offline, conflict-free replicated data types (CRDTs), used by libraries such as Yjs and Automerge, or rules on the server merge the edits.

The term comes from a 2019 essay by the research lab Ink & Switch, and apps such as Linear and Obsidian are often cited as examples. Sync services such as PowerSync, ElectricSQL and Dexie Cloud do much of the hard work for web and mobile apps. It changes the role of the backend: the server becomes a place to sync and back up, not the only source of truth.