How do we see the code we write show up on our screens?
What turns raw data and logic into buttons we can tap, pages we can scroll, and animations we can feel?

This process is called rendering, rendering is the process of transforming data and code into HTML that an end-user can see and interact with. This crucial step can happen in a few different places:

On the server: Where the website's data and logic live.
In the browser: On the user's device.

It can also be done all at once or partially, and each approach comes with its own trade-offs concerning user experience, performance, and developer experience.Now, let's explore the 10 rendering patterns for web apps:

Static Website:
Imagine you're preparing for a big event and need to send out invitations. With a static website, you create all your invitations (web pages) in advance, print them out, and then have them ready to hand over whenever someone asks for one. These pre-made pages are then uploaded as simple files to a storage space in the cloud, and a domain name points to them.
•
How it works: All web pages are put together upfront and uploaded as fixed, static files.
•
Analogy: It's like having a stack of pre-printed brochures for your business. When a customer walks in, you just hand them a brochure. You don't print a new one every time someone asks; it's already done.
•
Pros:
Works great, even today.
Simple to manage.
Low-cost hosting.
•
Cons:
Not ideal for websites where data changes frequently.
Only suitable for very basic websites without a lot of interactivity or dynamic content.
Frameworks: Hugo, 11t, and Jekyll.

Best for: Personal blogs, portfolios, documentation sites, marketing landing pages that rarely change.

Multi-Page Applications (MPA):
Think of a bustling custom bakery. Every time a customer places an order for a cake (representing a page request), the baker (the server) dynamically bakes a fresh cake from scratch based on that specific order, putting together the ingredients (HTML and data) right then and there. If you click on a new link, it's like ordering a completely new, freshly baked cake, leading to a full-page reload.
•
How it works: HTML and data are assembled dynamically on a server whenever a browser sends a request. The appearance of the website can change as the underlying data changes.
•
Analogy: Visiting amazon.com is a classic example. Every time you click a link, you get a new, dynamically generated page from their servers, like ordering a completely new dish at a restaurant where each order is prepared fresh.
•
Pros:
Handles dynamic data effectively.
Many of the biggest web apps still use this approach.
•
Cons:
The "full page reload" on every URL can feel "clunky" compared to smoother app experiences.
Can take at least a few hundred milliseconds or more for the page to render.
•
Frameworks/CMS: Ruby on Rails, Django, Laravel, and WordPress.

Best for: Large traditional websites like e-commerce (Amazon), forums, corporate portals.

Single Page Application (SPA):
Imagine an art studio with a single, large, blank canvas. When you enter, the artist (JavaScript) immediately starts painting the entire scene directly onto that one canvas, pulling in details and colors as needed. If you want to see a different scene, the artist doesn't get a new canvas; they simply paint over or adjust the existing one, making the transitions feel very smooth and instantaneous, all happening within that one "page" in the studio.
•
How it works: All user interface (UI) rendering occurs within the user's browser. It starts with one basic HTML page as a "shell," then JavaScript executes to render the UI and fetch any necessary data. Even with multiple "routes" or sections, these are updated by JavaScript in the browser, not by pointing to a new server page.
•
Analogy: Think of an interactive map application. You open it once, and then you can zoom, pan, search for locations, and get directions—all without the page ever reloading. All interactions happen seamlessly within that single map view.
•
Pros:
Feels instantaneous to the end user.
•
Cons:
Requires a large JavaScript bundle, which can make the initial page load quite slow.
Search engines, even today, struggle to understand content on dynamic routes, which is bad for SEO (Search Engine Optimization) or sharing content on social media.
•
Frameworks: AngularJS and React.

Best for: Web apps with rich interactivity—dashboards, chats, to-do apps, calendars.

Server-Side Rendering (SSR):
This is like a hybrid newspaper delivery service. The very first time you request the newspaper (the initial page load), a complete physical paper is printed and delivered directly to your door (the server renders everything dynamically). After that initial delivery, any subsequent updates, interactive elements, or navigation within the digital version of the newspaper are handled by a small, interactive app on your phone (client-side JavaScript takes over), giving you a smooth, app-like experience without needing a new physical paper for every small change.
•
How it works: HTML and data are rendered on the server for the initial page load. After this, client-side JavaScript "hydrates" the page, allowing it to function like a Single Page Application (SPA). It's a "best of both worlds" approach aiming for good initial load performance and a smooth interactive experience afterward.
•
Analogy: Imagine a restaurant that pre-cooks the main dish for efficiency (server-side render) so it's ready quickly when you sit down. But once it's served, you can add sauces, garnishes, and interact with the meal yourself (client-side JavaScript takes over) without sending it back to the kitchen.
•
Pros:
Offers the "best of both worlds" by providing a fast initial page load from the server while still enabling an app-like SPA experience afterward.
Likely the most popular rendering strategy today.
•
Cons:
Requires an actual server to run, which costs money.
On the initial page load, the app might feel "frozen" while the JavaScript is still executing to "take over" the rendering process (hydration).
•
Frameworks: Next.js, Nuxt, and SvelteKit (often called meta frameworks).

Best for: News sites, blogs, SaaS apps that need fast first paint + dynamic content.

Static Site Generation (SSG):
Think of a highly organized, pre-made meal service. All your meals (web pages) are cooked and perfectly packaged (rendered as HTML) in advance at a central kitchen (during the "build" process). When you order one, it's just delivered directly to you from this pre-made stock. But once you have it, you can heat it up, add sauces, or customize it within your own kitchen (JavaScript hydrates after the initial page load to add interactivity).
•
How it works: All HTML is rendered in advance, similar to static websites. However, like SSR, it then "hydrates" to JavaScript after the initial page load to provide an app-like experience. Websites using this approach are often called Jamstack sites.
•
Analogy: Building a LEGO set. All the pieces (HTML) are manufactured and sorted beforehand. When you get the box, everything is ready. You assemble the basic structure (initial static page), and then you can add motors or interactive elements to make parts move (hydration with JavaScript).
•
Pros:
Combines the simplicity and low-cost hosting of a static site with the app-like experience of an SPA.
•
Cons:
You have to redeploy your entire site whenever the underlying data changes.
Similar to SSR, the app might feel "frozen" during the initial page load while JavaScript executes for hydration.
•
Frameworks: Typically built by the same meta frameworks as SSR, such as Next.js, Nuxt, and SvelteKit.

Best for: Blogs, documentation, small e-commerce catalogs with infrequent updates.

Incremental Static Regeneration (ISR):
Imagine a very popular coffee shop that pre-brews large batches of coffee (like a static site). Most of the time, they just pour from what's already made (the cached content), which is incredibly fast. But, if a certain amount of time passes, or a specific ingredient runs out (cache invalidation rules), they don't shut down the whole shop; they automatically brew a new fresh batch for just that specific type of coffee (rebuild individual pages on the fly). This allows them to handle new data without a full "shop closure" (server deployment).
•
How it works: You deploy a static site, but individual pages can be rebuilt on the fly on your server when their cache is invalidated based on specific rules (e.g., after a certain amount of time). This provides a way to handle dynamic data without needing a full server deployment like SSR.
•
Analogy: A library with a main collection (static site) that's mostly unchanging. But for popular new releases or books with frequent updates, the librarian (the server process) can automatically get and update just those specific books periodically or when new editions are released, without having to reorganize the entire library.
•
Pros:
Offers the "best of both worlds" between SSG and SSR.
Allows handling dynamic data without a full server deployment.
Extremely fast due to permanent caching on a CDN (Content Delivery Network) for most requests.
•
Cons:
More complex to set up on your own.
You'll likely need a hosting provider that supports it out-of-the-box, like Vercel.
Still involves hydration, which can make the app feel "frozen" initially.
•
Frameworks: Started in Next.js.

Best for: Sites with lots of pages that need periodic updates, like blogs with comments or product catalogs with occasional price updates.

Partial Hydration:
Consider a vast, interactive museum exhibition. Instead of powering up every single exhibit at once when you walk in, which would take ages, the museum powers up the main entrance and the most important, visible exhibits first (components at the top of the page). Then, as you walk deeper into the museum or approach a new section, only those specific exhibits are powered up and made interactive (JavaScript is executed for those components as they become visible or needed).
•
How it works: Aims to solve the problem of an app feeling "frozen" on initial load due to large JavaScript execution. Instead of hydrating the entire page, it might render components at the top first, then wait until the user scrolls down before making other components interactive.
•
Analogy: A complex digital magazine. When you open it, you can immediately read the headlines and the top of the first article. The interactive elements like image carousels or video players further down the page only load and become active as you scroll to them.
•
Pros:
Improves the perceived performance and responsiveness of the app on initial load by making the top of the page interactive faster.
Reduces the initial JavaScript load and execution time.
•
Cons:
While not explicitly stated as a "con" in the source, it inherently adds complexity to the development process as you need to manage which parts hydrate when.
•
Supporting concepts: This pattern is facilitated by tools that support code splitting and lazy loading.

Best for: Long content pages with few interactive widgets (e.g., media articles, marketing pages).

Islands Architecture:
Imagine a vast, calm ocean (representing your static HTML) with several small, bustling islands scattered across it. The entire ocean is always there, providing the main content. However, only on these specific "islands" (interactive components) do you find active life and movement (JavaScript). Many parts of the ocean (static components) remain just water, meaning no boats (JavaScript) are ever sent there, making it very efficient.
•
How it works: The page starts with static HTML. JavaScript is only used to hydrate (make interactive) specific, isolated "islands" of interactivity. This is highly efficient because many components are often static and don't need JavaScript.
•
Analogy: A public bulletin board. The board itself and most of the notices tacked to it are static. But then there are a few QR codes or small digital screens embedded in the board that are interactive. You only need a battery (JavaScript) for those specific interactive parts, not the entire board.
•
Pros:
Extremely efficient: if a page is not interactive at all, no JavaScript is ever shipped to the client.
More efficient than hydrating the entire page.
•
Cons:
Requires a different way of thinking about component architecture.
•
Frameworks: Astro.

Best for: Mostly-static content sites with isolated interactive parts—think news sites with "like" buttons or comment forms.

Streaming SSR:
Think of receiving a long, important document. Instead of waiting for the entire document to be printed and bound before it's given to you, the printer starts sending you pages as soon as they are ready, in multiple chunks. You can start reading and interacting with the first pages while the printer is still working on the later ones, making the whole process feel much faster and more responsive.
•
How it works: This method allows the server to render content concurrently in multiple chunks rather than delivering everything all at once. It's a way to address inefficient hydration by making the UI interactive faster.
•
Analogy: Watching a video stream online. The video doesn't download entirely before it starts playing; it streams in chunks, allowing you to start watching almost immediately while the rest loads in the background.
•
Pros:
The UI becomes interactive faster.
Feels more performant to the end user.
•
Cons:
Not explicitly listed, but it adds complexity to the server-side setup.
•
Frameworks/Building Blocks: Supported in frameworks like Next.js 13 with the app directory, thanks to building blocks like React Server Components

Best for: Complex, data-heavy pages (e.g., dashboards, social media feeds) where rendering partial content ASAP improves UX.

Resumability:
Imagine a super-intelligent robot factory where robots are built in a unique way. When you "power on" a robot (load the website), all its blueprints, internal data, and even instructions for specific movements (like waving its arm or turning its head) are serialized and embedded directly into its physical structure (HTML). The actual "code" for those movements is then broken into tons of tiny, independent chips. When you tell the robot to wave, it doesn't need a huge "start-up" program; it just activates the tiny, specific chip needed for that exact wave, loading it only when required. No large initial power-up (hydration) is needed.
•
How it works: This is a new rendering paradigm. The website and all its data, including JavaScript event listeners, are serialized directly into the HTML. The actual JavaScript code is broken into many tiny chunks. This means the initial page load is always static HTML, and no hydration is needed. Any JavaScript required for interactivity is lazy-loaded only when specifically needed in the background.
•
Analogy: A self-sufficient modular home. Everything needed for the house to function is pre-built and embedded within its structure. If you want to turn on a light, the specific tiny wiring for that light switch is activated instantly, without needing to power up the entire house's electrical system first.
•
Pros:
Gets rid of hydration altogether, which is often a source of performance problems.
The initial page load is always static HTML.
JavaScript is lazy-loaded only when required for interactivity.
•
Cons:
It's a new and emerging paradigm, currently being pioneered by the Qwik framework. This means less community support or established best practices compared to more mature methods.
•
Frameworks: Qwik

Best for: Performance-critical apps with a need for almost instant load on mobile and slow networks.