Ben's Engineering Blog

Definitions of web terminology

Published on Thursday 31st March 2022 (last edited on Monday 23rd May 2022)


The act of turning data or state into some representation of HTML.

Server-side rendering (SSR)

A process that produces a string/text buffer of the HTML format by a server (a machine that is not the client). Note that this can be stored in buffers on a server as a cache or can be saved to files as static site generation.

Client-side rendering (CSR)

A string/text representation of HTML or HTMLElements that is created locally on the client (the same CPU, this includes web workers and service workers).


Hydration is the running of code that enables client-side interactivity on server-side rendered DOM. It has origins in databases and refers to how data is deserialized from some string buffer form. The reference of the term with the web is now more prevalent than with databases.

More recently it has been unfortunately been expanded to cover other aspects such as code bundling/elimination and execution.

Typically the term encompasses the following steps that many (but not all) frameworks use:

  • Parsing state from a JSON blob that is sent with the server-side rendered markup
  • Running any component initialization logic
  • Pairing up client-side rendered DOM elements with server-side rendered elements and adding event listeners, making corrections. Most frameworks do this via rendering VDOM.
    • Something said is "nuke server-side rendered" DOM, which is when the client rendered DOM does not match the server-side rendered DOM and removes the server tree and uses the client rendered version

Partial hydration / Island architecture

If your implementation of hydration starts by walking from a top-level node and ends up running over the whole UI, evaluating components, and deserializing the full state then partial hydration is identifying and instead running the above-mentioned hydration steps only on dynamic trees (aka not static trees). The islands refer to the dynamic trees.

Partial hydration is a form of dead code elimination, where the code being removed is anything to do with static UI. This includes static components render methods and any dependencies those render methods pull in. If the state is also serialized as a JSON blob then partial hydration can remove data used by static trees.

The saving is a ratio of how dynamic the page is. Partial hydration doesn't make the interactive parts faster just removes the costs of additional serialized state and additional code sent down, so overall the page should be faster than the "hydrating" the whole page. And note this is not a linear ratio, often dynamic parts contain larger code than the static parts (e.g. 90% static ‚Ȇ 90% reduction in payload size).

Note that this architecture is difficult to implement for SPAs as the router is often dynamic and therefore so is everything below. Partial hydration is an architecture, not a feature. Partial hydration / Island architecture is unrelated to progressive enhancement

Progressive hydration / Lazy hydration

Doing the process of hydration on interaction with a component or some other time after the page load.

It is important to note that this can make things noticeably slower as interactions have to do work after interaction they would have done at idle on the page load. So this architecture instead refers to other functionality at play such as reducing JS over the wire by sending granular component code and stopping at hydrating the whole subtree that can make the component interactive sooner.

JIT Hydration

Lazily initializing the client's state using data present in the UI (as HTML) rather than a JSON blob or additional source.

Progressive enhancement (PE)

The act of server rendering markup that has functionality using HTML features such as:

  • Forms with endpoints
  • Anchor tags with href

The above features are available without JS running on the client. A server should be ready to receive the browser's requests and do stuff.

Progressive enhancement can be implemented in any framework that supports server-side rendering. Although some frameworks have helpers for making this easier or the cow path. Additionally, the hydration](#hydration) step can then add event listeners to override the default browser functionality.

Note that not every interaction can be implemented using the HTML features (e.g. mouse drawing on a canvas) so JS is required in many scenarios and often doing it in JS has a better experience. Forms and anchor tags both do full page reloads which can disrupt the state present on the client (e.g. other input contents, background audio). Overriding the behavior to be a spa allows for transitions between and in some places can be faster as only a partial amount of the new page data needs to be changed. Sometimes using the browser functionality can be easier, and sometimes it is not (e.g. post request without redirect).

But doing PE is better than not doing PE. The site should be as functional as it can be because JS (the hydration) may have not run yet, at all or may have failed.

PE is disjoint from load performance. PE does not mean better performance either, using JS to only get partials from the server sends less than the content from a full page refresh thus is better performance.

Progressive enhancement is not partial hydration.

Design system

A collection of colour themes, component designs, layouts, and assets encompassing brand image and packaged up to be easily reusable throughout the site.

Hot module reloading / swapping

When changes happen during development it patches the changed functions rather than reloading the whole content and state.

Dynamic rendering

The server renders pages with data on demand.

HTML Frames

Sections of which content is purely server-side rendered. Note that server components may or may not be HTML frames if they don't serve HTML strings.

Static site generation (SSG)

Generation of static HTML through server-side rendering (or some bad methods that do client-side rendering and then capture the result on a headless browser). Normally done at build time. Note that SSGs can have dynamism through client-side rendering. If a tool has server-side rendering then that mechanism can be used to store the HTML content in a file to implement SSG.

Incremental static generation (ISG)

Similar to a static site generation. Where a static site generates on build/deploy. Incremental static generation is linked to a timed interval or a hook on the change of a data source. The hook fires an event that generates new pages to reflect the new data.

Time to interactive (TTI)

The time to which some form of hydration has finished adding event listeners with most of the functionality ready.

  • Event handlers are registered for the most visible page elements
  • The page responds to user interactions within 50¬†milliseconds

First contentful paint (FCP)

The time to display content from when the page starts loading (e.g. server initially responds, so this does not include the time to establish a connection). If SSR this is the time it takes to produce the HTML string and if doing purely client-side rendering then the time it takes for the JS to start running and produce the elements). This also includes initial layout working and image rendering.

Time to first byte (TTFB)

The time it takes for the server to initially respond. If streaming, this is the time for the first chunk. If not (aka buffering) this is the time for the content to be prepared and sent (aka a full SSR). Normally a measure of the hosting server rather.

No-JS / zero JS

Something with no JS running ever. This includes 3rd party scripts. Again most pages require some form of JS, something that runs no JS is not necessarily better.


Using JS to add interactivity to certain parts of a server-rendered UI in small amounts. (This is not progressive enhancement as it doesn't require implementing server functionality)

3rd party scripts

A script that is written out of house. Examples include Google Analytics, Google Tag Manager, etc

Static trees

A tree that does not change

const static_tree = <h1>Hello</h1>;
const still_static = <div>{*constant variable*}</div>;
const not_static = <h2>{new Date()}</h2>
const static_tree = <h1>Hello</h1>;
const still_static = <div>{*constant variable*}</div>;
const not_static = <h2>{new Date()}</h2>

not_static is dependent on a variable result and thus is a dynamic tree.


For VDOM or systems that need to recalculate trees after the result of an action. This term is given to the calculations for recomputing UI. Later the result of the re-render requires diffing to efficiently update the new UI.

Fine-grained reactivity

Reactivity in which knows about parts of the states and only does work in those areas.


E.g. changing content should not result in calculating title.toUppercase()

This is to do with partial updates to the state. Something that skips static trees is not really fine-grained reactivity.

Note that fine-grained reactivity may include re-rendering sections that are dynamic under the state.

Server component

Any component where its content is produced on the server either in HTML or an intermediate format.


The process of caching function return values against the inputs. If a function takes a long to compute the result and is rerun a lot then this can speed up getting the result as it takes a map lookup rather than a re-computation.

An auto-memoization compiler can wrap function calls with a cache lookup and storage.

Note that this is an optimization at call sites, this can be avoided via rearranging when data is calculated and passed through.

This technique incurs memory overhead due to the need to store all results of the function. And for many cases a map lookup can be slower than just doing the operation.


Something that mutates a specific part of the state.


Results of those actions. e.g. changing a value may require updating the content element in the templating interpolation.


Finding differences between an existing representation and a new representation.

Diffing techniques do not always apply to VDOM. Diffing can be done on structures that do not look like DOM. Such as a flat list.

Produces a diff/difference that can be used for reconciliation.

Conciliation / reconciliation

This applies to virtual DOM and other representations e.g. lists.

It is the act of taking the results of the diff and updating the UI. The diff should describe the minimum amount of work to update the UI).


Some notion of writing styles in JS. Normally via object literals that look like CSS syntax. Unsure whether this covers <style> JSX tags and template literals...


Frontend is what is interpreted by the client. Public and visible to all. Includes communication with backend (but not implementation).


Something that does not run on the client. Owned by an operator, distributes data and effects across clients. The backend includes the serving of content and HTTP responses etc

Full stack

The combination of frontend and backend. Full stack knowledge is knowing both sides of the network. A full stack framework has features spread across frontend and backend

Single page application (SPA)

A page that does not use the browser's built-in navigation to do page transitions. It does not mean that there is only one page, only that the browser internally thinks it is on the same page.

Can be faster as only have to update regions between pages, and can retain state between navigations. Implementations should be using the history API so that the browser's back buttons still function. New page contents can be generated using client-side rendering or by retrieving and injecting server-rendered content (e.g. turbolinks).

A SPA can be server rendered initially.

This architecture makes it simple to build a PWA.

Multi page application (MPA)

A page of which links cause inbuilt browser navigation. Pages are exclusively server-rendered (but parts of them can be changed via the client).

Progressive web application (PWA)

This encompasses a lot, but the main points are that it is built using web technologies but can do the following:

  • Installable (act like a native app)
  • Work offline (functionality does not require talking to a server all the time, some content is stored on the device)
  • Doesn't have to but uses several native APIs: camera, clipboard, background fetch, push notifications


Cannot change.


Can change.

DOM (Document object model)

The API for HTML elements. Every HTML element has some attributes and some children either being more elements, text, or comments. DOM elements can also interact with methods like .click().

Shadow DOM

A special form of DOM that is encapsulated inside the element. The internals of shadow dom are isolated from the whole DOM so that outside JS cannot reference and CSS cannot affect. CSS defined internally is scoped to the internal tree.

Virtual DOM / VDOM

The virtual DOM is a structure akin to the DOM. It is slimmer and has a subset of the API of the structures defined in the DOM JS spec e.g. HTMLElement. VDOM is a virtual representation of the document, actual DOM references the document (e.g. .click() isn't on VDOM structures).

It is used to add to or update the existing actual DOM / UI.

Universal JavaScript / Universal rendering

Running JavaScript produced that is derived or is the same source on both the client AND the server.

Isomorphic JavaScript

Same meaning as universal JavaScript.

Use of this should be discouraged as the (proper) definition of isomorphic in category theory doesn't make sense here.

Meta framework

A framework that is built upon one or more existing frameworks and wraps functionality. For example, nextjs that extends React.

Templating language

A language that can describe how to build some form of markup.

Imperative templating

A template language that has imperative notions of a declarative source.


Streaming is incremental sending parts enabling work to start happening without the whole of the resource being present. e.g a streaming renderer can start returning results before the whole thing has been rendered. Streaming hydration can start hydrating nodes before all the nodes are on the client.

Static analysis

Something that is statically analyzable is something of which behavior can be worked out ahead of time. It should be noted that some things that are deemed not to be statically analyzable can be made statically analyzable by introducing constraints on what can be written. It should also be used with caution as some things named under statically analyzable are but whose implementation is incredibly complex to build.


Some kind of language that is centered on content first. Markdown, HTML, and YML are based on content.


A program that:

  • Parses input into abstract syntax trees, concrete syntax trees, or some other source-based IR
  • Transforms IR
  • Returns some evaluatable result, or a collection of errors found

"compiling" is a compiler at work.


Similar to a compiler it is a source-to-source compiler. Source to source meaning the output is in the same format as the input. A transpiler is a subset of compilers.

"transpiling" is a transpiler at work.

Intermediate representation (IR)

A more abstract representation of the source, may not be reversible to the original source. e.g. operation canonicalization.


Non-centralized computation. Similar to a pure function (without side effects) these should be small map-like functions.

Note this is still run on serverless just that it abstracts away a lot of the behaviors of centralized server computations.


The definition/interface for interaction with something.

Headless browser

A browser that is controlled by a server rather than a user. Examples of headless browser tools include puppeteer, selinum and playright.


A single or a collection of programs that are used to build a program.


Something that acts as the entry point to a program. The framework interprets and operates over user code.

There are several kinds:

  • Backend / HTTP frameworks
  • Frontend frameworks
  • Parser frameworks
  • Test frameworks
  • Benchmark frameworks
HTTP framework

An abstraction for a server in receiving HTTP requests and returning HTTP responses. Examples: express, oak and axum.

Frontend framework

Code that only executes on the frontend

Fullstack framework

Code that only executes on the frontend and backend


Something that exposes functions that can be called and returns results.


Concatenation of source code from multiple sources and files into one or more files.

Dead code elimination (DCE)

Finding code that is never run or has no effect and making sure its representation doesn't end up in the final output.

Tree shaking

Tree shaking is a subset of DCE that mostly refers to removing top-level function declarations (from the abstract syntax tree, which is what the tree part refers to).

(whitespace) Minification

Remove unnecessary whitespace (new lines, tabs, spaces) from the source.


The whole operation or managing and running the program.


An API that is formalized in a specification and implemented by other parties.

Type checking

Validating that source code lines up with type definitions.

Type annotation

A piece of syntax that associates a type with a term.

Type inference

Identifying a type without using information from a type annotation.


Cannot change


Can change


A map that may or may not contain an already processed or downloaded asset