Reference

Glossary & Dictionary

Every term used across all 17 chapters, defined in one place. Click a category to jump, or type in the box to filter. Each entry links back to the chapter that teaches it in depth.

Web & HTTP #

client: A program that initiates a request over a network — in this course, almost always a web browser running your JavaScript. See Chapter 1.
server: A long-running program that listens for requests and sends back responses. Stays running between requests, unlike a script that runs once and exits. See Chapter 1.
HTTP: HyperText Transfer Protocol — the request/response text format almost the entire web is built on. Stateless: each request is independent, and the server can't send data unless asked. See Chapter 1.
request / response: The two halves of one HTTP exchange. A request has a method, a path, headers, and an optional body; a response has a status code, headers, and usually a body. See Chapter 1.
endpoint: A specific URL path a server responds to, usually paired with an HTTP method, e.g. POST /api/todos. See Chapter 9.
API: Application Programming Interface — the set of endpoints (or functions) a program exposes for others to call, without needing to know its internals. See Chapter 9.
REST: A loose convention for designing HTTP APIs around resources (nouns, like /todos) and standard methods (verbs, like GET/POST) rather than one-off action URLs. See Chapter 1.
JSON: JavaScript Object Notation — a text format for structured data ({ "id": 1, "title": "..." }) that both browsers and servers can parse natively. See Chapter 1.
CORS: Cross-Origin Resource Sharing — the browser security mechanism that blocks a page from one origin (domain/port) from freely calling an API on another, unless the server explicitly allows it via response headers. See Chapter 9.
DOM: Document Object Model — the browser's in-memory tree representation of a web page, which JavaScript can read and modify. Frameworks manage most direct DOM manipulation for you. See Chapter 6.
CLI: Command Line Interface — a program you interact with by typing commands into a terminal, as opposed to clicking a graphical interface. See Chapter 1.

JavaScript #

variable: A named reference to a value, declared with let (reassignable) or const (not reassignable). See Chapter 2.
function: A reusable, named block of code that can take inputs (parameters) and return a value. Arrow functions ((x) => x * 2) are a shorthand form. See Chapter 2.
object: A collection of key/value pairs, JavaScript's basic structure for grouping related data: { title: "Buy milk", done: false }. See Chapter 2.
array: An ordered list of values, e.g. ["a", "b", "c"], with built-in methods like map, filter, and push. See Chapter 2.
callback: A function passed into another function to be called later, often when an asynchronous operation finishes. Promises largely replaced deeply nested callbacks. See Chapter 2.
Promise: An object representing a value that isn't available yet but will be (or will fail) in the future. The foundation that async/await is built on top of. See Chapter 2.
async / await: Syntax that lets you write asynchronous, Promise-based code that reads top-to-bottom like synchronous code, instead of chaining .then() calls. See Chapter 2.
module: A single file of code that explicitly exports the values/functions it wants to share and imports what it needs from other files, instead of relying on global variables. See Chapter 2.
ESM: ECMAScript Modules — the standardized import/export module syntax now used across modern JavaScript, browsers, and Node.js. See Chapter 2.
template literal: A backtick-quoted string (`Hello, ${name}`) that can embed expressions directly inside ${...}, instead of building the string with + concatenation. Not to be confused with a Vue template, a different, unrelated use of the same word. See Chapter 2.
undefined: The default "nothing" value JavaScript gives you automatically — a property never set, an argument never passed. You rarely write it yourself; it's what's there when nobody set anything. See Chapter 2.
null: The "nothing" value a developer sets deliberately, to represent an intentional, known absence of a value, as opposed to undefined's "nobody set this." See Chapter 2.
type coercion: JavaScript automatically converting a value from one type to another to make an operation work (e.g. turning the number 0 into false for a loose == comparison), often in ways that surprise developers coming from a strictly-typed language. See Chapter 2.

TypeScript #

type: A description of the shape of a value (string, number, a specific object shape, etc.) that TypeScript checks at compile time, before the code ever runs. See Chapter 3.
interface: A named, reusable description of an object's shape (interface Todo { id: string; title: string }), usable by both a function's parameters and its return type. See Chapter 3.
generic: A type that takes another type as a parameter, e.g. Array<Todo> is an array specifically of Todo objects, not just "an array of anything." See Chapter 3.
type inference: TypeScript's ability to figure out a value's type automatically from context, without you writing an explicit annotation everywhere. See Chapter 3.
strict mode: A bundle of TypeScript compiler settings (like strictNullChecks) that catch more potential bugs at compile time, at the cost of needing more explicit types. See Chapter 3.
string literal type: A type so narrow it accepts exactly one specific string value (e.g. the type "pending" accepts only that exact string), as opposed to the general string type, which accepts any string. See Chapter 3.
enum: A TypeScript construct that groups named constants under one type and, unlike a type-only union, generates an actual JavaScript object that exists at runtime. See Chapter 3.
polymorphism: Writing one function or piece of code that works with several different concrete shapes or types, as long as each satisfies the same contract (interface). See Chapter 3.
structural typing: TypeScript's rule that any value with the right shape satisfies an interface automatically, whether or not it was ever explicitly declared as that interface — "if it has the right shape, it counts." See Chapter 3.

Packages & Tooling #

package: A shareable, versioned bundle of code, described by a package.json file, installed from a registry like npm. See Chapter 4.
dependency: A package your code relies on at runtime (as opposed to a devDependency, needed only while developing/building). See Chapter 4.
lockfile: A generated file that pins the exact version of every dependency (and every dependency's dependency), so installs are reproducible across machines. See Chapter 4.
semantic versioning (semver): A version number convention, MAJOR.MINOR.PATCH, where each segment signals the size of change: breaking, additive, or a fix. See Chapter 4.
monorepo: A single repository containing multiple related packages (e.g. a shared types package, a server, a client), built and versioned together. See Chapter 4.
workspace: A package manager feature for managing a monorepo: one config lists the package folders, and one install/build step can operate across all of them in dependency order. See Chapter 4.
bundler: A build tool that resolves your modules' import graph and combines/transforms them into files a browser can run efficiently. See Chapter 5.
dev server: A local server used only during development that serves your code (often unbundled, for speed) and can proxy API requests to a separate backend process. See Chapter 5.
Hot Module Replacement (HMR): A dev-server feature that swaps changed code into a running page instantly, without a full reload or losing current UI state. See Chapter 5.
transpile: Converting source code from one syntax/dialect (like TypeScript) into another (plain JavaScript) a runtime can execute directly. See Chapter 5.
tree shaking: A bundler optimization that removes exported code your app never actually imports/uses from the final output. See Chapter 5.

Frontend Framework #

component: A self-contained, reusable unit of UI combining a template, logic, and (usually) its own styles. See Chapter 6.
reactive: A value that, when changed, automatically causes anything depending on it (like a template) to update — without you manually re-rendering. See Chapter 6.
template: The declarative, HTML-like markup part of a component, describing what should render based on current state (v-if, v-for, {{ }} interpolation). See Chapter 6.
virtual DOM: An in-memory representation of the UI a framework diffs against the previous render, so it can apply only the minimal real DOM changes needed. See Chapter 6.
props: Data passed from a parent component down into a child component, read-only from the child's side. See Chapter 7.
emit: A child component notifying its parent that something happened, by firing a named event the parent can listen for. See Chapter 7.
slot: A placeholder in a component's template where a parent can inject its own markup, for flexible, wrapper-style components. See Chapter 7.
composable: A function (conventionally named useX) that bundles reusable reactive state and logic, callable from any component. See Chapter 7.
provide / inject: A mechanism for a parent component to make a value available to any descendant, at any depth, without passing it through props at every intermediate level. See Chapter 7.
single-page app (SPA): An app that loads one HTML page and then swaps content in and out with JavaScript, rather than requesting a full new page from the server for every navigation. See Chapter 7.

State Management #

store: A centralized object holding application-wide state, so any component can read or update it without passing data through many prop layers. See Chapter 8.
state: The current data an application is holding at a given moment — what's in the todo list, what page is active, and so on. See Chapter 8.
getter: A store value computed/derived from other state (like a completed-items count), recalculated automatically when its inputs change. See Chapter 8.
action: A store method that changes state, often asynchronously (e.g. call an API, then update local state with the result). See Chapter 8.
single source of truth: The principle that one piece of state should live in exactly one place, with everything else deriving from it, rather than several components keeping their own copies that can drift apart. See Chapter 8.

Backend #

framework: A library that provides the structure of your program (routing, request handling) and calls into your code, rather than your code calling into it at the top level. See Chapter 9.
route: A mapping from an HTTP method + path to the handler function that runs when a matching request arrives. See Chapter 9.
middleware: Code that runs as part of the request pipeline for cross-cutting concerns — logging, auth checks, CORS headers — independent of any single route's business logic. In a framework like Fastify this is implemented as a plugin (see that entry below for the broader, non-HTTP-specific sense of the term). See Chapter 9.
decorate: Attaching a shared singleton (a database handle, config, an event bus) onto the framework's app instance, so any route handler can reach it without re-importing it. See Chapter 9.

Databases #

SQL: Structured Query Language — the language for reading and writing rows in a relational database (SELECT, INSERT, UPDATE, DELETE). See Chapter 10.
table: A named collection of rows with a fixed set of columns, the basic unit of storage in a relational database. See Chapter 10.
foreign key: A column in one table that references a row's primary key in another table, enforcing that relationships stay valid (e.g. a todo can't reference a list that doesn't exist). See Chapter 10.
index: A database structure that speeds up lookups on a column at the cost of extra storage and slightly slower writes — the database's equivalent of a book's index. See Chapter 10.
prepared statement: A SQL query with ? placeholders, compiled once and reused with different parameter values — prevents SQL injection and is faster for repeated queries. See Chapter 10.
migration: A small, numbered, one-time script that changes the database schema (adds a column, a table, an index), applied in order and tracked so it never runs twice. See Chapter 10.
WAL (write-ahead logging): A SQLite journaling mode that writes changes to a separate log file first, allowing safe concurrent reads while a write is in progress. See Chapter 10.
pragma: A SQLite-specific command that reads or changes settings on a database connection itself (like journal mode or foreign key enforcement), rather than reading or writing rows. See Chapter 10.

Real-Time & Scheduling #

polling: The client repeatedly asking the server "anything new?" on a timer — simple, but wasteful and never truly instant. See Chapter 11.
Server-Sent Events (SSE): A one-way, long-lived HTTP connection the server uses to push named events to a browser as they happen, without the client re-asking. See Chapter 11.
EventSource: The browser API that opens and listens on an SSE connection: new EventSource("/api/live"), then .addEventListener("name", handler). See Chapter 11.
event bus: A server-side object that tracks connected clients and broadcasts events to all of them at once. See Chapter 11.
publish / subscribe (pub/sub): A pattern where publishers emit events without knowing who's listening, and subscribers register interest without knowing who publishes — decoupling the two sides. See Chapter 11.
scheduler: A component that runs jobs on a recurring timer, tracking when each job is next due. See Chapter 12.
job: A discrete unit of scheduled work, e.g. "check if a reminder is due" or "delete old log rows." See Chapter 12.
in-flight: Describes a job that has started but not yet finished — tracked so a scheduler doesn't start a second overlapping run of the same slow job. See Chapter 12.
concurrency: Multiple operations in progress during the same time window — a source of subtle bugs when they touch the same data. See Chapter 12.
idempotency: A property of an operation where running it more than once has the same effect as running it once — important for anything that might be retried or accidentally re-run, like a job that resumes after a crash. See Chapter 12.

Architecture #

plugin: A self-contained module that implements a shared interface/contract so it can be added to a system without modifying the system's core code. Fastify's own use of the word (see middleware above) is a special case of this same idea, scoped to the request/response pipeline. See Chapter 13.
dependency injection: Supplying a piece of code with the things it depends on (a database, a config) from outside, instead of it constructing or importing them itself — makes swapping/testing easier. See Chapter 13.
code generation: A build step that scans the filesystem for files matching a convention and writes out a registry/import file automatically, so nothing needs manual registration. See Chapter 13.
registry: A central list (often generated) of everything pluggable in a system — every connector, every route module, every component — that the core app can iterate over. See Chapter 13.

Design Systems #

design token: A named, reusable design decision (a color, a spacing value, a radius) instead of a hardcoded value repeated everywhere. See Chapter 14.
CSS custom property: A CSS variable (--name: value;), read with var(--name), that can be redefined per selector/theme without touching every rule that uses it. See Chapter 14.
dark mode: An alternate color theme, commonly implemented by reassigning semantic CSS custom properties under an attribute or class selector like [data-theme="dark"]. See Chapter 14.
scoped CSS: Component-local styles that only apply to that component's own markup, not to the rest of the page, preventing accidental leakage. See Chapter 14.
BEM: Block-Element-Modifier — a CSS class naming convention (.card__title--active) that keeps class names descriptive and reduces specificity conflicts. See Chapter 14.

Testing #

test runner: The tool that discovers, executes, and reports on your test files (e.g. Vitest), usually offering describe/it/expect style syntax. See Chapter 15.
unit test: A test of one small piece of logic in isolation, usually a pure function, with no real network or database involved. See Chapter 15.
integration test: A test that exercises several real pieces together — e.g. a route handler writing to an actual temporary database file — to catch bugs unit tests miss. See Chapter 15.
fixture: Reusable setup/teardown for tests — creating a temporary database, seeding sample data, cleaning up afterward. See Chapter 15.
mock: A fake stand-in for a real dependency, used sparingly at true boundaries (like an external network call) — overusing mocks can hide real integration bugs. See Chapter 15.
assertion: A statement in a test that a value must equal/match/satisfy some condition, e.g. expect(result).toBe(3); the test fails if it doesn't hold. See Chapter 15.

Security #

encryption at rest: Encrypting sensitive data before storing it, so a database file leak alone doesn't expose readable secrets. See Chapter 16.
symmetric encryption: Encryption using the same key to both encrypt and decrypt (e.g. AES-256-GCM), as opposed to asymmetric encryption's public/private key pairs. See Chapter 16.
initialization vector (IV): A random value generated fresh for every encryption operation, ensuring the same plaintext never produces identical ciphertext twice. See Chapter 16.
hashing: A one-way transformation used for passwords: you never decrypt a hash, you re-hash the input and compare. See Chapter 16.
salt: Random data mixed into a password before hashing, so two users with the same password get different stored hashes, defeating precomputed lookup-table attacks. See Chapter 16.
timing-safe comparison: A comparison function that always takes the same amount of time regardless of where two values first differ, preventing an attacker from guessing a secret byte-by-byte via response timing. See Chapter 16.

← Back to Table of Contents