Reference

Web Dev Tech Stack

A state-of-the-art map of the modern web development stack — the languages, runtimes, frameworks, build tools, styling systems, state & data libraries, backends, databases, ORMs, hosting platforms, DevOps tooling, version control, testing kit, and package managers you actually assemble apps from. Each technology carries what it is, when to reach for it, what to learn first, how mature it is, how steep the learning curve is, what it pairs with, the alternatives, the gotcha that bites people, and a link to the docs.

How to use: pick a category tab, narrow by Layer (frontend / backend / tooling…), or filter live by typing into the search box (matches across name, tagline, description, use cases, features, and more). Click any column header to sort — Maturity, Learning Curve, and Since are ranked sorts. Tap any code example for a plain-English explanation, and tap any highlighted term for what it stands for. Prerequisites, Pairs well with, and Alternatives link straight to the matching row. The technology column stays pinned as you scroll horizontally.

15 categories 120 technologies Last updated

Maturity

How established and production-proven a technology is right now.

  • ★ standard Industry-standard / default choice
  • ● mainstream Widely adopted & safe
  • ▲ rising Gaining traction, newer
  • ▼ legacy Mature but fading / maintenance mode

Learning Curve

Roughly how much effort it takes to get productive.

  • gentle Pick up in a day or two
  • moderate A few weeks to feel fluent
  • steep Significant ramp-up / deep concepts

Layer

Where a technology sits in the stack. Many span more than one — use the Layer filter above the table to narrow by one.

  • Language
  • Frontend
  • Backend
  • Full-stack
  • Styling
  • Database
  • Tooling
  • Infrastructure
Web Dev Glossary 26 terms

Click any term to see a beginner-friendly explanation. Cross-references inside an explanation open in a stacked modal — Escape closes them one at a time.

Technology Layer Maturity Learning Curve Since What it is Use cases Prerequisites Key features Pairs well with Alternatives Example Gotchas Built in Maintained by License Docs
HTML The markup language every web page is built from.
★ standard{ }▤
{ } Language▤ Frontend
★ standard gentle 1993

The HyperText Markup Language defines the structure and semantics of a web page — headings, paragraphs, links, forms, media — as a tree of elements the browser parses into the DOM. It’s declarative, not a programming language, and the living standard evolves continuously rather than in numbered versions since HTML5.
3 use cases The structural foundation of every web page and app. Show all
  • The structural foundation of every web page and app.
  • Semantic, accessible document markup for content and forms.
  • Email templates and the output target of every frontend framework.
 —
4 features Semantic elements (
,
  • Semantic elements (<article>, <nav>, <main>) for structure and a11y.
  • Native form controls, validation, and input types.
  • Built-in media: <video>, <audio>, <picture>, <canvas>.
  • A living standard — no version churn, broad backward compatibility.

HTML is forgiving to a fault — browsers silently recover from unclosed or misnested tags, so broken markup often looks fine until a screen reader or a CSS selector trips over it. Use semantic elements over a sea of <div>s, and validate to catch accessibility regressions early.

 n/a (markup) WHATWG (living standard) open standard
CSS The styling language that paints the web.
★ standard{ }▤◈
{ } Language▤ Frontend◈ Styling
★ standard moderate 1996

Cascading Style Sheets control the presentation of HTML — layout, colour, typography, animation, and responsiveness. The cascade and specificity rules decide which declarations win, and modern CSS has absorbed features (grid, flexbox, custom properties, container queries, nesting) that once required preprocessors or JavaScript.
3 use cases All visual styling and layout of web pages and apps. Show all
  • All visual styling and layout of web pages and apps.
  • Responsive and adaptive design via media and container queries.
  • Animations, transitions, and theming with custom properties.
4 features Flexbox and Grid for two-dimensional layout. Show all
  • Flexbox and Grid for two-dimensional layout.
  • Custom properties (CSS variables) and calc() for dynamic theming.
  • Container queries and :has() for component-aware styling.
  • Native nesting and cascade layers (@layer) without a preprocessor.

The cascade and specificity are where CSS bites — a stray !important or an over-specific selector quietly overrides everything downstream, and debugging means reasoning about source order, specificity, and inheritance all at once. Cascade layers and a consistent methodology tame this.

 n/a (stylesheet) W3C CSS Working Group open standard
JavaScript The language of the web — and increasingly, everywhere else.
★ standard{ }▤
{ } Language▤ Frontend
★ standard moderate 1995

The only programming language browsers run natively. A dynamically typed, multi-paradigm language standardized as ECMAScript, with a yearly spec cadence. It runs in the browser, on servers (Node, Deno, Bun), at the edge, and in build tools — and modern code ships as ESM modules.
3 use cases Client-side interactivity and SPA frameworks in the browser. Show all
  • Client-side interactivity and SPA frameworks in the browser.
  • Server-side and edge runtimes (Node.js, Deno, Bun, Workers).
  • Build tooling, scripting, and CLIs across the JS ecosystem.
4 features First-class functions, closures, and async/await for conc... Show all
  • First-class functions, closures, and async/await for concurrency.
  • Prototype-based objects with class syntax sugar.
  • ES modules, destructuring, optional chaining, and yearly new syntax.
  • Runs unchanged across browsers, servers, and edge runtimes.

The famous foot-guns are real — implicit type coercion (== vs ===), this binding that shifts with call site, and floating-point math where 0.1 + 0.2 !== 0.3. Lean on ===, arrow functions, and a linter, and reach for TypeScript once a project grows.

 n/a (specified language) Ecma TC39 (ECMAScript) open standard
TypeScript JavaScript with a type system bolted on at build time.
★ standard{ }🔧
{ } Language🔧 Tooling
★ standard moderate 2012

A typed superset of JavaScript from Microsoft: every valid JS file is valid TS, but you add static types the compiler checks before transpiling down to plain JavaScript. The types are erased at build time — they exist only to catch bugs and power editor autocomplete, never at runtime.
3 use cases Any non-trivial JavaScript codebase needing type safety. Show all
  • Any non-trivial JavaScript codebase needing type safety.
  • Large team projects where types document contracts and prevent regressions.
  • Library authoring where shipping .d.ts types is expected.
4 features Static structural typing erased at compile time — zero ru... Show all
  • Static structural typing erased at compile time — zero runtime cost.
  • World-class editor autocomplete, refactoring, and inline errors.
  • Generics, unions, and type inference for expressive contracts.
  • Ships .d.ts declaration files for typed library APIs.

Types are erased, so they don’t validate runtime data — JSON from an API can lie about its shape, and any or a careless cast silently disables all checking. Validate external input at the boundary (e.g. with a schema library) and keep strict mode on.

 TypeScript Microsoft + OSS community Apache-2.0
PHP The veteran server language that still powers most of the web.
★ standard{ }⚙
{ } Language⚙ Backend
★ standard gentle 1995

A dynamically typed server-side language designed for the web, embedded directly in HTML templates. Long mocked for its early inconsistencies, modern PHP (8.x) is a fast, type-hinted language with a strong framework ecosystem, and it still runs an enormous share of the web — WordPress alone powers a large slice of all sites.
3 use cases Server-rendered web apps and APIs (Laravel, Symfony). Show all
  • Server-rendered web apps and APIs (Laravel, Symfony).
  • Content management — WordPress, Drupal, and their plugin ecosystems.
  • Cheap, ubiquitous shared-hosting deployments.
4 features Embeddable in HTML with a simple request-per-script model. Show all
  • Embeddable in HTML with a simple request-per-script model.
  • Gradual typing, enums, and JIT compilation in PHP 8.
  • Composer package manager and a mature framework ecosystem.
  • Runs on virtually every host out of the box.

The ecosystem spans decades, so tutorials and Stack Overflow answers mix ancient mysql_* calls and global state with modern typed, framework-based code — and they look superficially alike. Target PHP 8.x, use a framework’s conventions, and ignore pre-PHP-7 advice.

 C The PHP Group + OSS community PHP License
Python Readable, batteries-included, and everywhere from web to AI.
★ standard{ }⚙
{ } Language⚙ Backend
★ standard gentle 1991

A dynamically typed, readability-first language used far beyond the web — in data science, machine learning, scripting, and automation. On the backend it powers fast async frameworks (FastAPI) and full-featured ones (Django), and optional type hints checked by external tools add safety to large codebases.
3 use cases Backend web APIs and full-stack apps (Django, FastAPI, Fl... Show all
  • Backend web APIs and full-stack apps (Django, FastAPI, Flask).
  • Data science, ML, and AI tooling and pipelines.
  • Automation, scripting, and glue code across systems.
 —
4 features Clean, indentation-based syntax with a huge standard libr... Show all
  • Clean, indentation-based syntax with a huge standard library.
  • Optional type hints checked by mypy / pyright (erased at runtime).
  • async/await for concurrent I/O in modern frameworks.
  • The dominant ecosystem for data, ML, and scientific computing.

Environment management is the classic pain — global installs, virtualenvs, and competing tools (pip, poetry, uv, conda) make reproducible setups fiddly. The Global Interpreter Lock also caps CPU-bound threading; reach for multiprocessing or async I/O instead.

 C (CPython) Python Software Foundation PSF License
Go Google’s simple, fast language for servers and tooling.
★ standard{ }⚙
{ } Language⚙ Backend
★ standard moderate 2009

A statically typed, compiled language from Google built for simplicity and concurrency. It compiles ahead of time to a single static binary with no runtime to install, has a tiny deliberate feature set, and ships goroutines and channels for lightweight concurrency — making it a favourite for backend services and cloud tooling.
3 use cases High-throughput backend services and microservices. Show all
  • High-throughput backend services and microservices.
  • CLI tools and cloud infrastructure (Docker, Kubernetes, Terraform).
  • Network servers where concurrency and a single binary matter.
 —
4 features Compiles to a single dependency-free static binary. Show all
  • Compiles to a single dependency-free static binary.
  • Goroutines and channels for cheap, built-in concurrency.
  • Fast compilation, gofmt, and a strong standard library.
  • Deliberately minimal — small language, fast to learn.

Go’s minimalism cuts both ways — verbose if err != nil error handling everywhere, and (until generics arrived in 1.18) repetitive code for generic containers. The deliberate lack of features that other languages take for granted frustrates some, but it’s the point: read-once, obvious code.

 Go (self-hosted) Google + OSS community BSD-3-Clause
Rust Memory safety without a garbage collector.
● mainstream{ }⚙
{ } Language⚙ Backend
● mainstream steep 2015

A systems language that guarantees memory and thread safety at compile time through its ownership and borrow-checker model — no garbage collector, no runtime overhead. It powers performance-critical backends, the fastest JavaScript build tools, and is a primary source language for WebAssembly.
3 use cases Performance-critical backend services and systems software. Show all
  • Performance-critical backend services and systems software.
  • JS toolchains compiled to native speed (SWC, Turbopack, Biome).
  • WebAssembly modules for CPU-heavy work in the browser.
 —
4 features Compile-time memory safety via ownership and borrowing — ... Show all
  • Compile-time memory safety via ownership and borrowing — no GC.
  • Zero-cost abstractions and predictable, native performance.
  • Fearless concurrency — data races caught at compile time.
  • Cargo: an excellent built-in build tool and package manager.

The borrow checker is a famously steep wall — ownership, lifetimes, and move semantics fight you constantly until they click, and compile times are slow. The payoff is that whole classes of bugs (use-after-free, data races) become impossible, but expect a real learning investment.

 Rust (self-hosted) Rust Foundation + OSS community MIT / Apache-2.0
WebAssembly Near-native speed in the browser, from any language.
● mainstream{ }▤
{ } Language▤ Frontend
● mainstream steep 2017

A portable binary instruction format — WASM — that runs at near- native speed in browsers and standalone runtimes. It’s a compile target, not a language you hand-write: code in Rust, C/C++, or Go compiles to a .wasm module that JavaScript can call, bringing heavy computation to the web.
3 use cases CPU-heavy browser work — image/video editing, games, simu... Show all
  • CPU-heavy browser work — image/video editing, games, simulations.
  • Porting existing C/C++/Rust libraries to run on the web.
  • Sandboxed plugin systems and edge compute (via WASI).
4 features Near-native execution speed in a sandboxed VM. Show all
  • Near-native execution speed in a sandboxed VM.
  • Compile target for Rust, C/C++, Go, and more.
  • Runs in every modern browser and standalone runtimes.
  • WASI extends it to server and edge compute outside the browser.

WASM can’t touch the DOM directly — every interaction crosses a JS boundary, and marshalling complex data across it can erase the speed win for chatty workloads. It shines on compute-bound tasks, not as a wholesale replacement for JavaScript UI code.

 n/a (bytecode target) W3C WebAssembly Working Group open standard
Node.js The runtime that brought JavaScript to the server.
★ standard⚙🔧
⚙ Backend🔧 Tooling
★ standard moderate 2009

The original server-side JavaScript runtime, built on Google’s V8 engine with an event-driven, non-blocking I/O model. It anchors the entire JS toolchain — almost every build tool, framework, and package runs on it — and its npm ecosystem is the largest package registry in existence.
3 use cases Backend APIs, servers, and full-stack frameworks (Next.js... Show all
  • Backend APIs, servers, and full-stack frameworks (Next.js, Nest).
  • The runtime under nearly all JS build tooling and CLIs.
  • Real-time services using its event loop and streams.
4 features Event-driven, non-blocking I/O on a single-threaded event... Show all
  • Event-driven, non-blocking I/O on a single-threaded event loop.
  • The npm registry — the largest package ecosystem anywhere.
  • Native ESM, the test runner, and --watch mode built in.
  • Yearly major releases — one Active LTS at a time.

Years of churn left two module systems coexisting — older CommonJS (require) and modern ESM (import) — and mixing them across packages still causes friction. New code should be ESM. Also pick an LTS line (24 or 22) for production, not the Current release.

 C++ / JavaScript OpenJS Foundation + OSS community MIT
Deno A secure, batteries-included runtime from Node’s creator.
● mainstream⚙🔧
⚙ Backend🔧 Tooling
● mainstream moderate 2018

A modern JavaScript and TypeScript runtime built in Rust on V8, created by Node’s original author to fix its early design regrets. It runs TypeScript with no build step, is secure by default (explicit permission flags for file, network, and env access), and Deno 2 added strong npm compatibility.
3 use cases TypeScript-first backends and scripts with no build step. Show all
  • TypeScript-first backends and scripts with no build step.
  • Secure-by-default tooling where permission sandboxing matters.
  • Edge functions and serverless on Deno Deploy.
4 features First-class TypeScript — runs .ts directly, no config. Show all
  • First-class TypeScript — runs .ts directly, no config.
  • Secure by default — explicit --allow-net/--allow-read flags.
  • Built-in formatter, linter, test runner, and bundler.
  • Web-standard APIs (fetch, Request) and npm compatibility (Deno 2).

Despite Deno 2’s npm compatibility, some packages that depend on deep Node internals or native addons still don’t run cleanly — verify your critical dependencies. The default global install pulls remote URL imports, which can surprise teams used to a single package.json lockfile.

 Rust Deno Land Inc. + OSS community MIT
Bun The fast all-in-one runtime, bundler, and package manager.
▲ rising⚙🔧
⚙ Backend🔧 Tooling
▲ rising moderate 2022

A blazing-fast JavaScript runtime written in Zig on Apple’s JavaScriptCore engine (not V8), bundling a runtime, package manager, bundler, and test runner into one binary. It aims for drop-in Node compatibility while being dramatically faster at install and startup. Anthropic acquired Bun in December 2025 — it powers Claude Code and stays MIT-licensed and open source.
3 use cases Fast local dev — install, run, test, and bundle from one ... Show all
  • Fast local dev — install, run, test, and bundle from one tool.
  • Node-compatible backends wanting quicker startup and installs.
  • Scripts and tooling where the all-in-one binary cuts setup.
4 features Runtime + package manager + bundler + test runner in one ... Show all
  • Runtime + package manager + bundler + test runner in one binary.
  • Built on JavaScriptCore for fast startup; very fast bun install.
  • Drop-in Node compatibility for most packages and APIs.
  • Native TypeScript and JSX execution with no build step.

Compatibility is most of Node, not all — packages leaning on obscure Node internals or native addons can still break, so test production-critical dependencies before switching. Being the youngest runtime here, it’s the least battle-tested at scale despite its momentum.

 Zig Anthropic (acq. Dec 2025) + OSS community MIT
V8 Google’s JavaScript engine that powers Chrome and Node.
★ standard🔧
🔧 Tooling
★ standard steep 2008

Google’s open-source, high-performance JavaScript and WebAssembly engine written in C++. It compiles JS to machine code with a JIT compiler and powers Chrome, Node.js, Deno, Electron, and Cloudflare’s edge — you rarely use it directly, but nearly everything you run sits on top of it.
3 use cases The engine embedded in Chrome, Node.js, Deno, and Electron. Show all
  • The engine embedded in Chrome, Node.js, Deno, and Electron.
  • Powering Cloudflare Workers’ isolate-based edge runtime.
  • Embedding a JS engine inside a C++ application.
4 features JIT compilation of JavaScript to native machine code. Show all
  • JIT compilation of JavaScript to native machine code.
  • Generational garbage collector tuned for web workloads.
  • Runs WebAssembly alongside JavaScript.
  • Lightweight isolates enable thousands of sandboxes per process.

You almost never touch V8 directly — it’s an implementation detail of the runtime you actually use. The trap is over-tuning to its JIT quirks (hidden-class deopts, micro-benchmarks) when the engine is so fast that readable code wins in practice.

 C++ Google BSD-3-Clause
Cloudflare Workers Serverless code running on V8 isolates at the edge.
● mainstream⚙☁
⚙ Backend☁ Infra
● mainstream moderate 2017

A serverless platform that runs your code on V8 isolates across Cloudflare’s global edge network — close to users, with near-zero cold starts. The underlying runtime, workerd, is open source, and Workers use web-standard APIs plus a storage suite (KV, D1, R2, Durable Objects) rather than full Node.
3 use cases Low-latency edge APIs and middleware close to users. Show all
  • Low-latency edge APIs and middleware close to users.
  • Serverless functions with near-zero cold starts at global scale.
  • Static-site backends paired with Cloudflare Pages.
4 features V8 isolates — near-zero cold starts, not per-request cont... Show all
  • V8 isolates — near-zero cold starts, not per-request containers.
  • Global edge network — code runs near every user.
  • Storage suite: KV, D1 (SQLite), R2, Durable Objects.
  • Open-source workerd runtime with web-standard APIs.

It’s not Node — there’s no filesystem, long-running processes are limited, and CPU time per request is capped, so you rely on web-standard APIs and Cloudflare’s storage primitives instead of arbitrary npm packages. Code written for a full Node server won’t lift-and-shift unchanged.

 C++ / Rust (workerd) Cloudflare Apache-2.0 (workerd)
Edge runtimes The web-standard runtime model behind edge & serverless functions.
▲ rising⚙☁
⚙ Backend☁ Infra
▲ rising moderate 2021

A family of lightweight runtimes — Vercel Edge Functions, Netlify Edge, Deno Deploy, and the WinterCG-aligned standard — that run a restricted, web-standard JavaScript environment (fetch, Request, Response, Web Streams) on global infrastructure rather than full Node. The trade is faster cold starts and global distribution for a smaller API surface.
3 use cases Latency-sensitive middleware, redirects, and personalizat... Show all
  • Latency-sensitive middleware, redirects, and personalization.
  • Lightweight serverless functions distributed near users.
  • Framework edge rendering (Next.js, SvelteKit) at the network edge.
4 features Web-standard APIs (fetch, Request, Response, streams). Show all
  • Web-standard APIs (fetch, Request, Response, streams).
  • Fast cold starts and global distribution over single-region servers.
  • WinterCG-aligned API surface for portability across providers.
  • Restricted vs Node — no filesystem, limited CPU/runtime per request.

“Edge” means a restricted runtime, not just a faster Node — Node-only APIs, native addons, and many npm packages won’t run, and CPU/time limits are tight. Reach for it for light, latency-sensitive logic; keep heavy or Node-dependent work on a regular server runtime.

 JavaScript / C++ Vercel / Netlify / WinterCG + others varies (mostly permissive)
React The component library that defined modern frontend.
★ standard▤
▤ Frontend
★ standard moderate 2013

A declarative JavaScript library for building user interfaces from composable components. Uses a virtual DOM and one-way data flow, and ships as a view layer you compose with a router, build tool, and state solution — or adopt a meta-framework that bundles those for you.
3 use cases Interactive SPAs and dashboards with lots of dynamic state. Show all
  • Interactive SPAs and dashboards with lots of dynamic state.
  • Design systems and reusable component libraries.
  • The base layer under a meta-framework like Next.js.
4 features Function components with hooks for state and side-effects. Show all
  • Function components with hooks for state and side-effects.
  • Virtual DOM diffing and reconciliation.
  • React Server Components for zero-JS server rendering.
  • The largest ecosystem and job market of any UI library.

React is just the view layer — you assemble routing, data fetching, and a build tool yourself (or adopt a meta-framework). The rules of hooks (no conditional hooks) and stale-closure bugs trip up newcomers.

 JavaScript Meta + OSS community MIT
Vue The approachable, progressively adoptable framework.
★ standard▤
▤ Frontend
★ standard gentle 2014

A progressive framework with single-file components (.vue files bundling template, script, and style). Its reactivity system tracks dependencies automatically, and you can drop it into a page or scale up to a full SPA with Vue Router and Pinia.
3 use cases SPAs where a gentle learning curve and clear conventions ... Show all
  • SPAs where a gentle learning curve and clear conventions matter.
  • Progressive enhancement — sprinkle Vue onto existing pages.
  • Teams wanting batteries-included official router + store.
4 features Single-file components with scoped styles. Show all
  • Single-file components with scoped styles.
  • Composition API with automatic, fine-grained reactivity.
  • Official router (Vue Router) and store (Pinia).
  • Experimental Vapor mode compiles away the virtual DOM.

Two API styles coexist — the older Options API and the newer Composition API (<script setup>); tutorials mix them, which confuses beginners. Prefer the Composition API for new code.

 TypeScript Evan You / Vue core team + OSS MIT
Svelte A compiler, not a runtime — reactivity that disappears at build.
● mainstream▤
▤ Frontend
● mainstream gentle 2016

A UI framework that shifts work to a compile step: it compiles your components into small, imperative vanilla JS that updates the DOM directly, so there’s almost no framework runtime to ship. Svelte 5’s runes ($state, $derived, $effect) make reactivity explicit and fine-grained.
3 use cases Performance- and bundle-size-sensitive apps and widgets. Show all
  • Performance- and bundle-size-sensitive apps and widgets.
  • Embeddable components dropped into other sites.
  • Developers who want less boilerplate than React.
4 features Compile-time reactivity — minimal runtime overhead. Show all
  • Compile-time reactivity — minimal runtime overhead.
  • Runes ($state/$derived/$effect) for explicit signals.
  • Scoped styles and transitions built in.
  • Tiny bundles versus virtual-DOM frameworks.

Svelte 5 replaced the old let-is-reactive magic and $: labels with runes — a real migration. Older tutorials and libraries written for Svelte 4 won’t match current syntax.

 TypeScript Svelte core team (Vercel-sponsored) + OSS MIT
Angular Google’s batteries-included, opinionated framework.
★ standard▤
▤ Frontend
★ standard steep 2016

A complete, opinionated framework (not just a view layer) from Google, built around TypeScript, dependency injection, and a powerful CLI. Recent versions move to standalone components, explicit Signals, and zoneless change detection, modernizing what was a heavyweight reputation.
3 use cases Large enterprise apps needing strong structure and conven... Show all
  • Large enterprise apps needing strong structure and conventions.
  • Teams that want routing, forms, HTTP, and i18n in one package.
  • Long-lived codebases where consistency beats flexibility.
4 features Full framework: router, forms, HTTP client, DI, CLI. Show all
  • Full framework: router, forms, HTTP client, DI, CLI.
  • Signals + zoneless change detection in modern versions.
  • Standalone components (no NgModules required).
  • First-class TypeScript and RxJS integration.

The steepest curve of the mainstream frameworks — DI, decorators, modules vs standalone, and RxJS are a lot to absorb at once. The framework has also churned its idioms (modules → standalone, zones → signals) across versions.

 TypeScript Google + OSS community MIT
SolidJS React-like ergonomics with true fine-grained reactivity.
▲ rising▤
▤ Frontend
▲ rising moderate 2021

A reactive UI library with JSX that looks like React but has no virtual DOM. Components run once; fine-grained signals update only the exact DOM nodes that depend on changed state, giving excellent performance and tiny bundles.
3 use cases Performance-critical UIs where React's re-render model is... Show all
  • Performance-critical UIs where React’s re-render model is a bottleneck.
  • Developers who like JSX but want finer reactivity.
  • Interactive widgets with a minimal footprint.
4 features Fine-grained signals — no virtual DOM, no re-renders. Show all
  • Fine-grained signals — no virtual DOM, no re-renders.
  • JSX syntax familiar to React developers.
  • SolidStart meta-framework for SSR.
  • Very small runtime and fast benchmarks.

It looks like React but isn’t — components run once, so destructuring props or calling a signal outside a tracking scope silently breaks reactivity. The mental model differs more than the syntax suggests.

 TypeScript Ryan Carniato + OSS community MIT
Preact A 3 KB React-compatible alternative.
● mainstream▤
▤ Frontend
● mainstream gentle 2015

A fast, ~3 KB alternative to React with the same modern API. A preact/compat shim lets most React libraries run on it unchanged, so you can shrink an existing React app’s bundle or build new lightweight widgets.
3 use cases Bundle-size-sensitive apps and embeddable widgets. Show all
  • Bundle-size-sensitive apps and embeddable widgets.
  • Drop-in shrink of an existing React app via preact/compat.
  • Browser extensions and ads where every KB counts.
3 features ~3 KB runtime with React-compatible hooks API. Show all
  • ~3 KB runtime with React-compatible hooks API.
  • preact/compat aliases most React libraries.
  • Signals package for fine-grained reactivity.

“React-compatible” is ~95% — some libraries lean on React internals and need the preact/compat alias configured, and a few don’t work at all. Test third-party React components before committing.

 JavaScript Jason Miller + OSS community MIT
Alpine.js jQuery for the modern web — behavior in your markup.
● mainstream▤
▤ Frontend
● mainstream gentle 2019

A tiny (~15 KB) framework for sprinkling reactive behavior directly into HTML via x- attributes — no build step, no components, no virtual DOM. Ideal for adding interactivity to server-rendered pages.
3 use cases Adding interactivity to server-rendered HTML (Laravel, Ra... Show all
  • Adding interactivity to server-rendered HTML (Laravel, Rails, Django).
  • Small dropdowns, modals, tabs without a full SPA framework.
  • Projects that want zero build tooling.
3 features Declarative x-data / x-show / x-on attributes in markup. Show all
  • Declarative x-data / x-show / x-on attributes in markup.
  • No build step — drop in a single script tag.
  • Tiny footprint, pairs with Tailwind for the ‘TALL’ stack.

Great for sprinkles, painful for real app state — there’s no component model or routing, so complex UIs become a tangle of attributes. Reach for a real framework once logic outgrows the markup.

 JavaScript Caleb Porzio + OSS community MIT
Lit Tiny library for fast, standards-based Web Components.
● mainstream▤
▤ Frontend
● mainstream moderate 2019

A lightweight library from Google for building reusable Web Components — custom elements that work in any framework or none. Uses tagged-template literals for fast, declarative rendering with reactive properties.
3 use cases Framework-agnostic design systems and shared component li... Show all
  • Framework-agnostic design systems and shared component libraries.
  • Components that must work across React, Vue, and plain HTML.
  • Long-lived widgets built on web standards, not a framework.
3 features Standards-based custom elements — run anywhere. Show all
  • Standards-based custom elements — run anywhere.
  • Reactive properties with efficient template rendering.
  • ~5 KB core; decorators for ergonomic TypeScript.

Web Components bring their own quirks — Shadow DOM style encapsulation, form-association gaps, and SSR that’s less mature than framework rendering. Great for portable widgets, less so for full apps.

 TypeScript Google + OSS community BSD-3-Clause
htmx Access AJAX, WebSockets & more straight from HTML attributes.
▲ rising▤
▤ Frontend
▲ rising gentle 2020

A small library that lets any HTML element issue HTTP requests and swap the returned HTML fragment into the page via attributes (hx-get, hx-post, hx-target). It pushes rendering back to the server, shrinking or eliminating client-side JavaScript for many apps.
3 use cases Server-rendered apps that want SPA-like interactivity wit... Show all
  • Server-rendered apps that want SPA-like interactivity without a JS framework.
  • Backends in Go, Python, PHP, or Ruby driving the UI with HTML fragments.
  • Teams minimizing frontend build complexity.
3 features AJAX, WebSockets, SSE via HTML attributes — minimal JS. Show all
  • AJAX, WebSockets, SSE via HTML attributes — minimal JS.
  • Server returns HTML fragments, not JSON.
  • ~14 KB, no build step, no dependencies.

The interactivity ceiling is real — rich client-side state (drag-drop, complex forms, offline) still wants a JS framework. And every interaction is a server round-trip, so latency and endpoint sprawl can grow.

 JavaScript Big Sky Software + OSS community BSD-2-Clause
Next.js The default full-stack React framework.
★ standard▦▤
▦ Full-stack▤ Frontend
★ standard moderate 2016

Vercel’s React meta-framework and the most common way to ship a React app in production. The modern App Router is built on React Server Components and supports every rendering mode — SSR, SSG, and ISR — alongside server actions, file-system routing, and built-in image and font optimization.
3 use cases Production React apps that need SSR or SSG out of the box. Show all
  • Production React apps that need SSR or SSG out of the box.
  • Content sites, dashboards, and e-commerce on one framework.
  • Teams that want routing, data fetching, and an API layer bundled.
4 features App Router built on React Server Components. Show all
  • App Router built on React Server Components.
  • SSR, SSG, and ISR per route — mix and match.
  • Server actions and file-system routing.
  • Built-in image, font, and script optimization.

The App Router’s server/client split is a real mental shift — the "use client" boundary, where data fetching may run, and caching defaults all trip people up. It also leans toward Vercel’s platform; self-hosting works but some features (ISR, image optimization) need extra setup elsewhere.

 TypeScript Vercel + OSS community MIT
React Router Routing library turned full-stack React framework.
★ standard▦▤
▦ Full-stack▤ Frontend
★ standard moderate 2014

Long the de-facto router for React, v7 absorbed Remix’s framework features so the same package now spans a plain client-side router up to a full SSR framework with loaders, actions, and nested routing. You adopt it as a library or opt into “framework mode” for the batteries-included experience.
3 use cases Client-side routing in any React SPA. Show all
  • Client-side routing in any React SPA.
  • Full-stack React apps wanting loaders/actions without Next.js.
  • Migrating an existing Remix app — it’s the same code now.
4 features Nested routes with data loaders and actions. Show all
  • Nested routes with data loaders and actions.
  • Works as a plain router or a full SSR framework.
  • Framework mode is the former Remix, merged in.
  • Vite-based dev and build in framework mode.

The Remix-to-React-Router-v7 merge means docs, tutorials, and package names from before the rename now point at “framework mode” — expect confusion about which name and version a given guide assumes. Library mode and framework mode also look quite different.

 TypeScript Remix team (Shopify) + OSS MIT
Nuxt The full-stack framework for Vue.
★ standard▦▤
▦ Full-stack▤ Frontend
★ standard moderate 2016

Vue’s meta-framework — what Next.js is to React. It adds file-system routing, SSR / SSG, auto-imports, and a server engine (Nitro) that deploys to almost any host or edge runtime. A large module ecosystem covers auth, content, images, and SEO.
3 use cases Production Vue apps needing SSR, SSG, or hybrid rendering. Show all
  • Production Vue apps needing SSR, SSG, or hybrid rendering.
  • Content-heavy sites via Nuxt Content.
  • Teams wanting Vue with conventions and auto-imports.
4 features File-system routing and component auto-imports. Show all
  • File-system routing and component auto-imports.
  • SSR, SSG, and hybrid rendering per route.
  • Nitro server engine deploys anywhere, including the edge.
  • Rich module ecosystem (content, image, auth, SEO).

The magic — auto-imports, implicit server/client boundaries, and module conventions — is convenient until something breaks and you have to figure out where a function came from. Pinning module versions across a Nuxt major upgrade can also be fiddly.

 TypeScript Nuxt core team + OSS community MIT
SvelteKit The official app framework for Svelte.
● mainstream▦▤
▦ Full-stack▤ Frontend
● mainstream gentle 2022

Svelte’s full-stack framework, built on Vite. It adds file-system routing, load functions, form actions, and an adapter system that targets Node, serverless, static, or edge hosts — mixing SSR, SSG, and SPA rendering per route.
3 use cases Production Svelte apps with SSR or static output. Show all
  • Production Svelte apps with SSR or static output.
  • Small-to-medium apps wanting minimal boilerplate.
  • Sites deployed to varied hosts via swappable adapters.
4 features File-system routing with load functions and form actions. Show all
  • File-system routing with load functions and form actions.
  • Adapters for Node, serverless, static, and edge targets.
  • Per-route choice of SSR, SSG, or client rendering.
  • Vite-powered dev server with fast HMR.

You must pick the right adapter for your host — deploy errors often trace back to using adapter-auto or the wrong target. And SvelteKit rides Svelte’s own churn, so a Svelte 5 runes migration ripples into your app code too.

 TypeScript Svelte core team (Vercel-sponsored) + OSS MIT
Astro Content-first framework that ships zero JS by default.
● mainstream▦▤
▦ Full-stack▤ Frontend
● mainstream gentle 2021

A framework optimized for content-heavy sites. Its islands architecture renders pages to static HTML and ships JavaScript only for the interactive components you explicitly hydrate — and those islands can be React, Vue, Svelte, or Solid in the same project. It also supports SSR when you need a server.
3 use cases Blogs, docs, and marketing sites where speed and SEO matter. Show all
  • Blogs, docs, and marketing sites where speed and SEO matter.
  • Content sites that need a few interactive islands, not a full SPA.
  • Mixing components from React, Vue, and Svelte in one project.
4 features Islands architecture — zero JS shipped by default. Show all
  • Islands architecture — zero JS shipped by default.
  • Use React, Vue, Svelte, or Solid components together.
  • Static output by default, SSR via adapters.
  • Built-in content collections with typed frontmatter.

It shines for content but fights you for app-like UI — heavily interactive dashboards with shared client state cut against the islands grain. Watch the hydration directives (client:load vs client:visible): over-hydrating quietly throws away Astro’s zero-JS advantage.

 TypeScript Astro Technology Company + OSS MIT
Gatsby The React static-site generator that defined the JAMstack era.
▼ legacy▦▤
▦ Full-stack▤ Frontend
▼ legacy moderate 2015

A React static-site generator built around a GraphQL data layer that pulls content from CMSes, Markdown, and APIs at build time. It popularized the JAMstack but has lost momentum to Next.js and Astro since the Netlify acquisition, and is best treated as a legacy choice for new projects.
3 use cases Maintaining existing Gatsby sites and their plugin ecosys... Show all
  • Maintaining existing Gatsby sites and their plugin ecosystem.
  • Content sites sourcing from many CMSes via one GraphQL layer.
  • Static marketing and documentation sites (legacy stacks).
4 features Unified GraphQL data layer over many sources. Show all
  • Unified GraphQL data layer over many sources.
  • Large plugin ecosystem for CMSes and transforms.
  • Image optimization and progressive loading built in.
  • Static output with optional SSR / DSG modes.

Momentum has clearly shifted away — issues and plugins go stale, and the GraphQL-everything data layer is a lot of ceremony for a simple site. Reach for Astro or Next.js on greenfield work; keep Gatsby for sites already built on it.

 JavaScript Netlify MIT
Qwik Resumability instead of hydration — instant-loading apps.
▲ rising▦▤
▦ Full-stack▤ Frontend
▲ rising steep 2022

A framework built around resumability: instead of replaying app setup on the client (hydration), it serializes execution state into the HTML and resumes exactly where the server left off, downloading JavaScript only as the user interacts. The goal is constant startup time regardless of app size.
3 use cases Large apps where hydration cost dominates startup time. Show all
  • Large apps where hydration cost dominates startup time.
  • Content + commerce sites needing fast interactivity at scale.
  • Teams willing to adopt a newer model for time-to-interactive.
4 features Resumability — no hydration replay on load. Show all
  • Resumability — no hydration replay on load.
  • Fine-grained lazy loading of JS per interaction.
  • JSX syntax familiar to React developers.
  • Qwik City meta-framework for routing and SSR.

Resumability changes how you write code — the $ boundaries that mark lazy-loadable, serializable code are unfamiliar and easy to get wrong, and not every value can be serialized across the server/client gap. The ecosystem is also much smaller than React’s or Vue’s.

 TypeScript Builder.io + OSS community MIT
Remix Web-standards full-stack framework — now charting its own course.
● mainstream▦▤
▦ Full-stack▤ Frontend
● mainstream moderate 2021

A full-stack framework built on web fundamentals — fetch, Request / Response, forms, and progressive enhancement — with nested routes, loaders, and actions. Its framework features merged into React Router v7, and the Remix name is now being reframed as a standalone, model-agnostic full-stack framework (the v3 direction).
3 use cases Apps that lean on web standards and progressive enhancement. Show all
  • Apps that lean on web standards and progressive enhancement.
  • Form-heavy UIs where loaders/actions map cleanly to routes.
  • Following the framework’s v3 standalone direction.
4 features Loaders and actions colocated with nested routes. Show all
  • Loaders and actions colocated with nested routes.
  • Built on Web Fetch API Request/Response primitives.
  • Progressive enhancement — forms work without JS.
  • Framework features now live inside React Router v7.

Remix’s identity is in flux — its React framework features became React Router v7, while the Remix name is being repositioned as a separate v3 project. Check carefully which “Remix” a tutorial or package means before starting new work.

 TypeScript Remix team (Shopify) + OSS MIT
Vite The default frontend build tool — instant dev, optimized builds.
★ standard🔧▤
🔧 Tooling▤ Frontend
★ standard gentle 2020

A frontend build tool that serves source over native ES modules in development — no bundling, so the dev server starts instantly and HMR stays fast as the app grows — and produces an optimized bundle for production (currently via Rollup, migrating to the Rust-based Rolldown). It’s framework-agnostic, with official plugins for React, Vue, Svelte, and more.
3 use cases Default build tool for new React, Vue, or Svelte projects. Show all
  • Default build tool for new React, Vue, or Svelte projects.
  • Fast local dev with instant startup and HMR.
  • Library builds via its library mode.
4 features No-bundle native-ESM dev server — instant startup. Show all
  • No-bundle native-ESM dev server — instant startup.
  • Fast HMR that stays flat as the app grows.
  • Rollup-based production builds (moving to Rolldown).
  • Rich plugin API, compatible with many Rollup plugins.

Dev runs on native ESM while production is bundled by Rollup, so the two pipelines can differ — a bug that only shows up in the production build usually traces to that gap or to a dependency that isn’t valid ESM. VoidZero, Vite’s maintainer, was acquired by Cloudflare in June 2026, but Vite stays MIT-licensed, open source, and vendor-neutral.

 TypeScript VoidZero (Cloudflare) + OSS community MIT
webpack The long-reigning bundler that powered the SPA era.
● mainstream🔧▤
🔧 Tooling▤ Frontend
● mainstream steep 2012

The bundler that defined frontend builds for a decade. Its loader and plugin model can transform virtually any asset, and code-splitting plus tree-shaking made large SPAs shippable. Still everywhere in established codebases, but new projects increasingly pick Vite for speed and simpler config.
3 use cases Maintaining and extending existing webpack codebases. Show all
  • Maintaining and extending existing webpack codebases.
  • Complex builds needing fine-grained loader/plugin control.
  • Apps with non-standard asset pipelines.
4 features Loader system transforms any asset type. Show all
  • Loader system transforms any asset type.
  • Code splitting and tree-shaking.
  • Huge plugin ecosystem built over a decade.
  • Module Federation for micro-frontends.

The config is famously sprawling — loaders, plugins, and resolve rules pile up, and builds get slow on large apps. It’s mature rather than cutting-edge; greenfield projects usually start with Vite instead unless they need a webpack-specific feature like Module Federation.

 JavaScript webpack team + OSS community MIT
esbuild An extremely fast bundler and minifier written in Go.
● mainstream🔧▤
🔧 Tooling▤ Frontend
● mainstream gentle 2020

A bundler, transpiler, and minifier written in Go that’s one to two orders of magnitude faster than JavaScript-based tools. It powers dependency pre-bundling inside Vite and many other toolchains, and works standalone for fast library or server builds.
3 use cases Blazing-fast transpilation and bundling in larger toolcha... Show all
  • Blazing-fast transpilation and bundling in larger toolchains.
  • Bundling Node.js / serverless backends and CLIs.
  • Library builds where build speed matters most.
4 features Go-based — 10–100× faster than JS bundlers. Show all
  • Go-based — 10–100× faster than JS bundlers.
  • Bundling, transpiling (TS/JSX), and minification in one tool.
  • Used under the hood by Vite and others.
  • Simple API and small, predictable output.

Speed comes from doing less — esbuild deliberately skips full type checking (it strips types, it doesn’t verify them) and has a smaller plugin ecosystem than Rollup or webpack. Run tsc --noEmit separately for type safety, and check plugin coverage before relying on it as your only bundler.

 Go Evan Wallace + OSS community MIT
Rollup The bundler of choice for JavaScript libraries.
★ standard🔧▤
🔧 Tooling▤ Frontend
★ standard moderate 2015

A bundler that pioneered ES module-based tree-shaking and produces clean, minimal output — which made it the default for publishing libraries. Vite uses Rollup for its production builds, so its plugin ecosystem reaches far beyond standalone use.
3 use cases Bundling JavaScript/TypeScript libraries for publishing. Show all
  • Bundling JavaScript/TypeScript libraries for publishing.
  • Producing clean ESM, CJS, and UMD outputs from one source.
  • The production-build engine inside Vite.
4 features Best-in-class tree-shaking and clean output. Show all
  • Best-in-class tree-shaking and clean output.
  • Multiple output formats (ESM, CJS, UMD) at once.
  • Mature, well-documented plugin API.
  • Powers Vite’s production bundling.

Rollup is tuned for libraries, not apps — it has no dev server, and app-style features (HMR, asset handling) come from Vite layered on top. It’s also JavaScript-based, so it’s slower than esbuild; the Rust-based Rolldown is being built as its faster successor.

 TypeScript Rollup team + OSS community MIT
Parcel The zero-config bundler that just works.
● mainstream🔧▤
🔧 Tooling▤ Frontend
● mainstream gentle 2017

A bundler built around zero configuration — point it at an HTML entry and it infers the rest, installing transforms as needed. It caches aggressively and uses Rust- and SWC-based internals for speed, making it a low-ceremony choice for small to medium projects.
3 use cases Quick prototypes and small apps with no config overhead. Show all
  • Quick prototypes and small apps with no config overhead.
  • Bundling static sites and multi-page apps from HTML entries.
  • Beginners who want a bundler that works without setup.
4 features Zero-config — infers transforms from the entry. Show all
  • Zero-config — infers transforms from the entry.
  • Aggressive multi-core caching for fast rebuilds.
  • Built-in dev server with HMR.
  • Rust/SWC-based internals for speed.

Zero-config is great until you need to customize — escaping the defaults is less documented than webpack’s or Vite’s explicit config. Its mindshare has also shrunk as Vite became the default low-config option, so community help is thinner.

 JavaScript Parcel team + OSS community MIT
Turbopack Vercel’s Rust-based successor to webpack.
▲ rising🔧▤
🔧 Tooling▤ Frontend
▲ rising gentle 2022

An incremental bundler written in Rust by Vercel, designed as webpack’s successor for large apps. It ships inside Next.js — powering its dev server and, increasingly, production builds — with function-level incremental computation so only what changed is recomputed.
3 use cases Fast dev and builds inside Next.js. Show all
  • Fast dev and builds inside Next.js.
  • Large React apps where webpack build times hurt.
  • Teams on the Vercel/Next.js stack adopting the default tooling.
4 features Rust-based with function-level incremental computation. Show all
  • Rust-based with function-level incremental computation.
  • Powers the Next.js dev server and builds.
  • Fast HMR that scales to large apps.
  • Designed as a drop-in webpack replacement in Next.js.

Turbopack is tightly coupled to Next.js — it isn’t a general-purpose, standalone bundler you drop into any project the way Vite is. It’s also newer than its rivals, so feature parity with webpack loaders and the surrounding ecosystem is still filling in.

 Rust Vercel MIT
SWC A Rust-based platform for fast JS/TS transpilation.
● mainstream🔧
🔧 Tooling
● mainstream moderate 2019

The “Speedy Web Compiler” — a Rust-based platform that transpiles and minifies JavaScript and TypeScript far faster than Babel. Next.js uses it to replace Babel and Terser, and many test runners and bundlers plug it in for fast TS/JSX compilation.
3 use cases Drop-in faster replacement for Babel in build pipelines. Show all
  • Drop-in faster replacement for Babel in build pipelines.
  • Fast TypeScript/JSX transforms inside Next.js and test runners.
  • Custom transforms via SWC plugins (Wasm).
4 features Rust-based — far faster than Babel. Show all
  • Rust-based — far faster than Babel.
  • Transpiles TS/JSX and minifies JS.
  • Powers Next.js’s compilation and minification.
  • Wasm plugin system for custom transforms.

Like esbuild, SWC transpiles without full type checking — types are stripped, not verified — so keep tsc in your pipeline. Its plugin ecosystem is smaller than Babel’s, and authoring SWC (Wasm) plugins is far more involved than a Babel plugin.

 Rust SWC project + OSS community Apache-2.0
Babel The JavaScript compiler that brought modern syntax everywhere.
● mainstream🔧
🔧 Tooling
● mainstream moderate 2014

The classic JavaScript transpiler — it lets you write modern JS (and JSX, TypeScript) and compiles it down to syntax older browsers understand. Its preset and plugin system shaped a generation of build tooling; newer projects often swap it for SWC or esbuild on speed, but it remains ubiquitous for its plugin ecosystem.
3 use cases Transpiling modern JS/JSX/TS for broad browser support. Show all
  • Transpiling modern JS/JSX/TS for broad browser support.
  • Custom AST transforms via Babel plugins.
  • Maintaining toolchains and codebases built around Babel.
4 features Presets (@babel/preset-env, -react, -typescript). Show all
  • Presets (@babel/preset-env, -react, -typescript).
  • Vast plugin ecosystem for syntax and AST transforms.
  • Targets specific browsers via browserslist.
  • The reference implementation for new JS proposals.

Babel is JavaScript-based and slow on large codebases — the main reason SWC and esbuild displaced it for raw transpilation. It still wins on plugin breadth, so the common pattern is fast tools for builds and Babel only where a specific plugin is required.

 JavaScript Babel team + OSS community MIT
Rolldown Rust-based, Rollup-compatible bundler — Vite’s future engine.
▲ rising🔧▤
🔧 Tooling▤ Frontend
▲ rising gentle 2024

A bundler written in Rust that aims to be a drop-in, Rollup-compatible replacement at a fraction of the build time. It’s being adopted as Vite’s production bundler (shipped as “rolldown-vite”), unifying the dev and build paths and replacing the current esbuild + Rollup split.
3 use cases Faster production builds inside Vite (rolldown-vite). Show all
  • Faster production builds inside Vite (rolldown-vite).
  • Dropping into Rollup-based pipelines for a speed boost.
  • Bundling large apps and libraries where build time matters.
4 features Rust-based — far faster than Rollup. Show all
  • Rust-based — far faster than Rollup.
  • Rollup-compatible API and plugin interface.
  • Becoming Vite’s production bundler (rolldown-vite).
  • Built by the VoidZero team alongside Vite and Oxc.

It’s still maturing — Rollup compatibility is high but not perfect, so exotic plugins or edge-case config may not port cleanly yet. Maintained by VoidZero (acquired by Cloudflare in June 2026) and MIT-licensed, it stays open source and vendor-neutral alongside Vite.

 Rust VoidZero (Cloudflare) + OSS community MIT
Tailwind CSS Utility-first CSS you compose in your markup.
★ standard◈▤
◈ Styling▤ Frontend
★ standard moderate 2017

A utility-first framework where you style by composing tiny classes (flex, pt-4, text-center) directly in markup instead of writing bespoke CSS files. The compiler scans your templates and emits only the utilities you actually use, keeping the shipped stylesheet small. v4 rewrote the engine in Rust (“Oxide”) with tree-shaking-style JIT generation and a CSS-first config (@theme) that drops the old tailwind.config.js for most projects.
3 use cases Rapidly styling component-based UIs without context-switc... Show all
  • Rapidly styling component-based UIs without context-switching to CSS files.
  • Design systems where spacing, color, and type scales are enforced by tokens.
  • Teams that want consistent, low-specificity CSS with tiny production bundles.
4 features Utility classes mapped to a configurable design-token scale. Show all
  • Utility classes mapped to a configurable design-token scale.
  • v4 Rust engine (‘Oxide’) with Lightning CSS built in — no PostCSS setup needed.
  • CSS-first config via the @theme directive (no JS config file required).
  • JIT compilation emits only the classes your templates reference.

Markup gets verbose — long class strings are the trade for never writing CSS, so lean on component extraction or @apply sparingly. v4’s CSS-first config and Rust engine are a real migration from v3’s tailwind.config.js; older tutorials and plugins may not match.

 Rust / TypeScript Tailwind Labs MIT
Sass The veteran CSS preprocessor — variables, nesting, mixins.
● mainstream◈
◈ Styling
● mainstream gentle 2006

The original CSS preprocessor. You write .scss (or indented .sass) with variables, nesting, mixins, functions, and partials, and Sass compiles it down to plain CSS. The modern reference implementation is Dart Sass. Native CSS custom properties and nesting now cover some of what Sass pioneered, but its modules, loops, and mixins still go beyond the platform.
3 use cases Large hand-written stylesheets that benefit from partials... Show all
  • Large hand-written stylesheets that benefit from partials and mixins.
  • Design systems built on Sass maps, functions, and loops.
  • Legacy and CMS-themed projects where Sass is already the standard.
4 features Variables, nesting, mixins, and functions for DRY stylesh... Show all
  • Variables, nesting, mixins, and functions for DRY stylesheets.
  • @use / @forward module system replacing the old global @import.
  • Partials and loops to generate repetitive CSS programmatically.
  • Dart Sass is the canonical, actively maintained compiler.

Native CSS caught up — nesting and custom properties are now built into browsers, so reach for Sass for its programmatic features (loops, maps, mixins), not just nesting. The legacy @import is deprecated; use @use/@forward, and the old JS-based LibSass is dead — use Dart Sass.

 Dart Sass core team + OSS community MIT
PostCSS Transform CSS with JavaScript plugins.
★ standard◈🔧
◈ Styling🔧 Tooling
★ standard moderate 2013

A tool that parses CSS into an abstract syntax tree and lets JavaScript plugins transform it — Autoprefixer adds vendor prefixes, postcss-preset-env polyfills future syntax, others minify or lint. PostCSS does almost nothing on its own; it’s the plugin pipeline that build tools and frameworks (including older Tailwind) run CSS through.
3 use cases Auto-adding vendor prefixes via Autoprefixer in a build p... Show all
  • Auto-adding vendor prefixes via Autoprefixer in a build pipeline.
  • Polyfilling modern CSS syntax for older browsers.
  • Powering a framework’s CSS transform step (e.g. Tailwind v3).
4 features Plugin architecture — compose transforms over a CSS AST. Show all
  • Plugin architecture — compose transforms over a CSS AST.
  • Autoprefixer and postcss-preset-env are the canonical plugins.
  • Integrates into Vite, webpack, and most bundlers out of the box.
  • Each plugin is small and single-purpose, Unix-style.

It’s infrastructure, not a feature — PostCSS alone changes nothing, so its value lives entirely in the plugins you enable. Don’t confuse it with a preprocessor like Sass: it transforms CSS rather than giving you a richer authoring language (though plugins can emulate parts of that).

 JavaScript Andrey Sitnik + OSS community MIT
CSS Modules Locally-scoped CSS class names, by default.
● mainstream◈▤
◈ Styling▤ Frontend
● mainstream gentle 2015

A bundler convention, not a library: you write plain CSS in a *.module.css file, import it into a component, and the build renames each class to a unique, locally-scoped identifier. This kills the global namespace collisions that plague large CSS codebases while keeping you in ordinary CSS. Supported natively by Vite, webpack, and Next.js.
3 use cases Component-scoped styles in React/Vue without a CSS-in-JS ... Show all
  • Component-scoped styles in React/Vue without a CSS-in-JS runtime.
  • Avoiding global class-name collisions in large codebases.
  • Teams that prefer real CSS files over utility classes or template literals.
4 features Class names auto-hashed to be locally scoped per file. Show all
  • Class names auto-hashed to be locally scoped per file.
  • Plain CSS authoring — no new syntax to learn.
  • Built into Vite, webpack, Parcel, and Next.js.
  • composes keyword to share rules between local classes.

Dynamic, prop-driven styling is awkward — you compose static classes rather than interpolate values, so runtime-themed styles need CSS variables or a different tool. Class names are strings on the imported object, so typos fail silently unless you add TypeScript typing.

 CSS OSS community (bundler-implemented) MIT
styled-components CSS-in-JS — styled React components via tagged templates.
▼ legacy◈▤
◈ Styling▤ Frontend
▼ legacy moderate 2016

The library that popularized CSS-in-JS for React: you write real CSS inside tagged template literals to produce styled components, with props driving dynamic styles and automatic scoping. It’s runtime-based — styles are generated as the app renders — which is now seen as a cost versus zero-runtime alternatives. Active development has slowed and the maintainers have flagged it as in maintenance mode.
3 use cases Existing React codebases already built on styled-components. Show all
  • Existing React codebases already built on styled-components.
  • Highly dynamic, prop-driven component styling.
  • Co-locating styles with components in a single file.
4 features Tagged-template CSS that produces scoped styled components. Show all
  • Tagged-template CSS that produces scoped styled components.
  • Props and theme context drive dynamic styles at runtime.
  • Automatic critical-CSS extraction during SSR.
  • ThemeProvider for app-wide design tokens.

The runtime cost is the headline knock — generating styles during render hurts performance and clashes with React Server Components, which is why the ecosystem is drifting to zero-runtime options. The project is now in maintenance mode, so prefer Emotion or a zero-runtime tool for greenfield apps.

 JavaScript Max Stoiber + OSS (maintenance mode) MIT
Emotion Performant, framework-flexible CSS-in-JS.
● mainstream◈▤
◈ Styling▤ Frontend
● mainstream moderate 2017

A CSS-in-JS library offering both a styled-components-style API and a css prop for inline styles. It’s known for being faster and lighter than its predecessors and is framework-flexible — widely used standalone and as the styling engine under component libraries like MUI. Like all runtime CSS-in-JS, it carries a render-time cost that newer zero-runtime tools avoid.
3 use cases React apps wanting CSS-in-JS with strong performance. Show all
  • React apps wanting CSS-in-JS with strong performance.
  • Component libraries needing a flexible styling primitive (e.g. MUI).
  • Dynamic, theme-driven styles co-located with components.
4 features Two APIs — the css prop and a styled() factory. Show all
  • Two APIs — the css prop and a styled() factory.
  • Source maps and labels for debuggable generated classes.
  • Powers popular component libraries such as MUI.
  • Smaller, faster runtime than older CSS-in-JS libraries.

It’s still runtime CSS-in-JS — styles are computed during render, which adds overhead and complicates React Server Components, so SSR streaming needs care. For new apps prioritizing performance, a zero-runtime option like vanilla-extract or utility CSS may be a better fit.

 TypeScript Emotion team + OSS community MIT
UnoCSS The instant, on-demand atomic CSS engine.
▲ rising◈▤
◈ Styling▤ Frontend
▲ rising moderate 2021

An atomic-CSS engine by Anthony Fu that generates utility classes on demand from your source, with no fixed set of rules — everything is defined through presets you compose, including a Tailwind/Windi-compatible preset. It’s built for speed (no parsing of a huge CSS file) and is highly extensible via custom rules, shortcuts, and variants.
3 use cases Utility-first styling with faster builds and full customi... Show all
  • Utility-first styling with faster builds and full customization.
  • Projects wanting Tailwind-like utilities but a pluggable engine.
  • Defining bespoke design-system utilities via presets and rules.
4 features On-demand generation — only classes you use are produced. Show all
  • On-demand generation — only classes you use are produced.
  • Preset-driven; Tailwind-compatible preset included.
  • Custom rules, shortcuts, and variants for bespoke utilities.
  • First-class Vite integration and a fast core engine.

The flexibility is also the cost — without a chosen preset you get no utilities at all, and config differs enough from Tailwind that copy-pasted Tailwind snippets may need preset tweaks. A smaller ecosystem and documentation surface than Tailwind means more self-service.

 TypeScript Anthony Fu + OSS community MIT
vanilla-extract Zero-runtime, type-safe CSS-in-TypeScript.
▲ rising◈▤
◈ Styling▤ Frontend
▲ rising moderate 2021

A CSS-in-TS library where you author styles in .css.ts files using TypeScript, and the build compiles them to static CSS at build time — so there’s zero styling runtime in the browser. You get type-checked class names, theme contracts, and variables with the safety of TypeScript and none of the render-time cost of styled-components/Emotion.
3 use cases Type-safe styling with no client-side CSS-in-JS runtime. Show all
  • Type-safe styling with no client-side CSS-in-JS runtime.
  • Design systems wanting compile-time-checked theme contracts.
  • Performance-sensitive React/SSR apps avoiding runtime style generation.
4 features Styles compiled to static CSS — zero runtime cost. Show all
  • Styles compiled to static CSS — zero runtime cost.
  • Type-safe class names, themes, and variables.
  • createTheme / theme contracts for design tokens.
  • Build-plugin integrations for Vite, webpack, and esbuild.

Styles are static by design — there’s no per-render dynamic interpolation like runtime CSS-in-JS, so prop-driven variation uses recipes, variants, or CSS variables instead. It needs a build-tool plugin and a TypeScript setup, so it isn’t a drop-in for plain-JS or no-build projects.

 TypeScript Seek (vanilla-extract team) + OSS MIT
Redux Toolkit The official, opinionated, batteries-included Redux.
★ standard▤
▤ Frontend
★ standard moderate 2019

The modern, recommended way to write Redux. Plain Redux (2015) demanded heavy boilerplate; Redux Toolkit (“RTK”) wraps it with createSlice, Immer-powered “mutating” reducers, the Thunk middleware, and configured stores — cutting the ceremony dramatically. RTK Query adds a built-in data-fetching/caching layer for talking to an API.
3 use cases Large apps wanting a single predictable, debuggable globa... Show all
  • Large apps wanting a single predictable, debuggable global store.
  • Teams that value Redux DevTools time-travel and strict conventions.
  • Codebases standardizing on RTK Query for server-state caching.
4 features createSlice generates actions + reducers with Immer's mut... Show all
  • createSlice generates actions + reducers with Immer’s mutating syntax.
  • configureStore wires DevTools and sensible middleware by default.
  • RTK Query for data fetching, caching, and invalidation.
  • Strong TypeScript inference throughout.

It’s still Redux underneath — actions, reducers, selectors, and a single store are more architecture than small apps need. The “mutating” reducer syntax only works because Immer is inside createSlice; mutating state anywhere else still breaks things.

 TypeScript Redux team + OSS community MIT
Zustand A tiny, hooks-based store with almost no boilerplate.
● mainstream▤
▤ Frontend
● mainstream gentle 2019

A minimal state-management library from the Poimandres collective. You create a store with a single hook and read or update state from any component — no providers, reducers, or action types required. It’s tiny, unopinionated, works outside React, and has become the go-to lightweight alternative to Redux.
3 use cases Apps wanting global state without Redux's ceremony. Show all
  • Apps wanting global state without Redux’s ceremony.
  • Sharing state across components with a single hook.
  • Lightweight stores in libraries or non-React contexts.
4 features Single create() hook — no context provider needed. Show all
  • Single create() hook — no context provider needed.
  • Selector subscriptions to minimize re-renders.
  • Middleware for persistence, Immer, and Redux DevTools.
  • Tiny bundle; usable outside React.

The freedom is a double edge — no enforced structure means large apps can drift into ad-hoc stores and tangled updates. Naive selectors that return new objects can over-render, so reach for useShallow or fine-grained selectors as the store grows.

 TypeScript Poimandres (pmndrs) + OSS MIT
Jotai Bottom-up atomic state for React.
● mainstream▤
▤ Frontend
● mainstream gentle 2020

An atomic state-management library from Daishi Kato (Poimandres). State is built from small, composable atoms that you read and write with a useAtom hook, and derived atoms recompute automatically when their dependencies change. The bottom-up, primitive-first model avoids a single monolithic store and the re-render pitfalls of context.
3 use cases Fine-grained shared state without a single global store. Show all
  • Fine-grained shared state without a single global store.
  • Derived/computed state that recomputes from dependencies.
  • React apps wanting Recoil-style atoms with a smaller footprint.
4 features Composable atoms as the unit of state. Show all
  • Composable atoms as the unit of state.
  • Derived atoms recompute from their dependencies.
  • No provider required for the default store.
  • Integrations for persistence, Query, and async atoms.

Atomic thinking is a different mental model — many tiny atoms can sprawl, and tracking which derived atom depends on what gets harder at scale. Async atoms integrate with Suspense, which is powerful but adds its own learning curve.

 TypeScript Daishi Kato / Poimandres + OSS MIT
MobX Transparent reactive state via observables.
● mainstream▤
▤ Frontend
● mainstream moderate 2015

A state library built on transparent functional-reactive programming: you mark state as observable, derive values with computed, and components wrapped in observer re-render automatically when the data they read changes. You mutate state directly — MobX tracks the dependency graph and updates only what’s affected, an OOP-friendly contrast to Redux’s immutable flow.
3 use cases Apps preferring mutable, object-oriented state over reduc... Show all
  • Apps preferring mutable, object-oriented state over reducers.
  • Complex derived/computed values that must stay in sync.
  • Teams wanting automatic, fine-grained re-render tracking.
4 features Observable state with automatic dependency tracking. Show all
  • Observable state with automatic dependency tracking.
  • Computed values cached and recomputed only when needed.
  • observer components re-render on exactly the reads that change.
  • Direct mutation — no immutable-update boilerplate.

The “magic” reactivity can surprise you — forget the observer wrapper and a component silently won’t update, and reading observables outside a tracked context misses changes. The mutable, decorator-heavy style is a sharp philosophical break from the immutable Redux ecosystem.

 TypeScript Michel Weststrate + OSS community MIT
TanStack Query Async server-state — fetching, caching, revalidation done right.
★ standard▤
▤ Frontend
★ standard moderate 2019

The de-facto standard for managing server state in the browser (formerly React Query). It handles fetching, caching, background revalidation, deduping, pagination, and mutations behind a useQuery/useMutation hook — so you stop hand-rolling loading flags and stale-data bugs around your API calls. It’s transport- agnostic (works with REST, GraphQL, or anything that returns a promise) and ships adapters for React, Vue, Svelte, and Solid.
3 use cases Caching and revalidating REST/GraphQL data without a glob... Show all
  • Caching and revalidating REST/GraphQL data without a global store.
  • Pagination, infinite scroll, and optimistic mutations.
  • Eliminating manual loading/error/stale state boilerplate.
4 features useQuery / useMutation hooks with smart caching by key. Show all
  • useQuery / useMutation hooks with smart caching by key.
  • Background refetching, deduping, and stale-while-revalidate.
  • Infinite queries, pagination, and optimistic updates.
  • Framework adapters for React, Vue, Svelte, and Solid.

It manages server state, not client state — don’t reach for it to hold UI state like modal toggles (use a store for that). Cache keys and staleTime/gcTime tuning matter: a wrong key shares or splits caches in surprising ways, and defaults that feel “too eager” to refetch trip people up.

 TypeScript Tanner Linsley / TanStack + OSS MIT
SWR Lightweight data fetching with stale-while-revalidate.
● mainstream▤
▤ Frontend
● mainstream gentle 2019

A small React data-fetching library from Vercel, named after the HTTP stale-while-revalidate strategy: return cached data first, then refetch in the background and update. A single useSWR(key, fetcher) hook gives you caching, revalidation on focus/reconnect, and deduping with minimal setup — a lighter-touch alternative to TanStack Query.
3 use cases Simple, fast data fetching in React (especially Next.js) ... Show all
  • Simple, fast data fetching in React (especially Next.js) apps.
  • Auto-revalidating reads on window focus and network reconnect.
  • Lightweight caching without configuring a full query client.
4 features useSWR hook: cache-first, revalidate-in-background. Show all
  • useSWR hook: cache-first, revalidate-in-background.
  • Revalidation on focus, reconnect, and interval.
  • Request deduping and optimistic mutate().
  • Tiny footprint; first-class Next.js integration.

It’s intentionally lean — for heavy needs like infinite pagination, complex mutations, or fine-grained cache control, TanStack Query offers more out of the box. Aggressive default revalidation (refetch on focus) can surprise you; disable it per-call when it isn’t wanted.

 TypeScript Vercel + OSS community MIT
Apollo Client The full-featured GraphQL client with a normalized cache.
● mainstream▤
▤ Frontend
● mainstream steep 2016

A comprehensive client for talking to a GraphQL API. Its headline feature is a normalized in-memory cache that stores entities by ID and keeps queries across the app consistent, plus useQuery/useMutation hooks, optimistic UI, subscriptions, and local-state management. Powerful, but heavier than transport-agnostic fetch libraries.
3 use cases Apps with a substantial GraphQL API needing entity-level ... Show all
  • Apps with a substantial GraphQL API needing entity-level caching.
  • Consistent shared data across many components via a normalized cache.
  • GraphQL subscriptions, optimistic UI, and pagination.
4 features Normalized cache keyed by entity ID for cross-query consi... Show all
  • Normalized cache keyed by entity ID for cross-query consistency.
  • useQuery / useMutation hooks plus subscriptions.
  • Optimistic responses and cache updates.
  • Local state can live alongside server data in the cache.

The normalized cache is the power and the complexity — cache normalization, type policies, and manual cache updates after mutations are a real learning curve. It’s GraphQL-only and comparatively heavy; for REST or simple needs a fetch-based library is lighter. urql is a leaner GraphQL alternative.

 TypeScript Apollo (apollographql) + OSS MIT
XState State machines and statecharts for predictable logic.
● mainstream▤
▤ Frontend
● mainstream steep 2017

A library for modeling application logic as finite state machines and statecharts. Instead of scattered booleans, you declare explicit states and the transitions between them, so impossible states become unrepresentable. It’s framework-agnostic — usable in React, Vue, Node, or vanilla JS — and pairs with visual tooling from Stately to design and inspect machines.
3 use cases Complex multi-step flows (wizards, checkout, auth) with c... Show all
  • Complex multi-step flows (wizards, checkout, auth) with clear states.
  • Eliminating impossible/invalid UI states via explicit transitions.
  • Logic you want to visualize, document, and test as a diagram.
4 features Finite state machines and hierarchical/parallel statecharts. Show all
  • Finite state machines and hierarchical/parallel statecharts.
  • Guards, actions, and invoked actors/services.
  • Framework-agnostic core with React/Vue/Svelte bindings.
  • Visual editor and inspector from Stately.

Statecharts are a paradigm shift — the upfront modeling and dense API (actors, guards, context, services) are overkill for simple state and have a steep curve. Reach for it when flows are genuinely complex; a boolean or a small store is fine for the rest.

 TypeScript Stately (David Khourshid) + OSS MIT
Express The minimal, ubiquitous Node web framework.
★ standard⚙
⚙ Backend
★ standard gentle 2010

The de-facto standard web API framework for Node.js — a thin, unopinionated layer over the HTTP server giving you routing and a middleware pipeline, and almost nothing else. You assemble validation, auth, and an ORM yourself. Express 5 finally shipped after years on 4.x, modernizing async error handling.
3 use cases Lightweight REST APIs and microservices in Node. Show all
  • Lightweight REST APIs and microservices in Node.
  • Prototypes and glue services where you want minimal ceremony.
  • Teaching the fundamentals of HTTP routing and middleware.
4 features Minimal core: routing plus a middleware chain. Show all
  • Minimal core: routing plus a middleware chain.
  • Enormous ecosystem of compatible middleware packages.
  • Express 5 awaits rejected promises in route handlers.
  • Runs almost anywhere Node does.

Unopinionated means you own every decision — validation, structure, and error handling are bolt-ons, so large Express codebases drift in style. Most middleware is community-maintained and varies in quality; vet what you depend on.

 JavaScript OpenJS Foundation + OSS community MIT
Fastify Fast, low-overhead Node framework built around JSON schemas.
● mainstream⚙
⚙ Backend
● mainstream moderate 2016

A Node.js web framework focused on throughput and developer experience. Its headline feature is schema-based validation and serialization — you declare a JSON Schema per route and Fastify validates input and compiles a fast serializer for the response, which also feeds automatic OpenAPI docs.
3 use cases High-throughput REST APIs where Express overhead matters. Show all
  • High-throughput REST APIs where Express overhead matters.
  • Services that benefit from schema validation and typed routes.
  • Plugin-structured apps using Fastify’s encapsulation model.
4 features JSON Schema validation and compiled fast serialization. Show all
  • JSON Schema validation and compiled fast serialization.
  • Encapsulated plugin architecture for modular apps.
  • Strong TypeScript support and route type inference.
  • Lifecycle hooks and built-in structured logging (Pino).

The schema-first model is the win and the friction — skipping schemas throws away most of Fastify’s speed and type safety. Its plugin encapsulation (decorators, register scope) is powerful but trips up newcomers expecting Express-style global middleware.

 JavaScript Fastify team (OpenJS Foundation) + OSS MIT
NestJS Opinionated, Angular-inspired TypeScript backend framework.
● mainstream⚙
⚙ Backend
● mainstream steep 2017

A structured, opinionated Node.js framework written in TypeScript whose architecture borrows heavily from Angular — modules, providers, and dependency injection. It runs on top of Express or Fastify and adds a consistent project structure plus first-class support for REST, GraphQL, WebSockets, and microservices.
3 use cases Large, long-lived backends where structure and convention... Show all
  • Large, long-lived backends where structure and conventions matter.
  • Enterprise teams wanting DI, modules, and testability out of the box.
  • APIs spanning REST, GraphQL, and microservice transports.
4 features Dependency injection and modular architecture (Angular-st... Show all
  • Dependency injection and modular architecture (Angular-style).
  • Decorators for controllers, routes, guards, and pipes.
  • Runs on Express or Fastify adapters interchangeably.
  • First-class REST, GraphQL, WebSocket, and microservice support.

The heaviest learning curve of the Node frameworks — DI, modules, providers, decorators, and metadata reflection are a lot before you write real logic. Overkill for a small service, and the abstraction layers can obscure what plain Express would make obvious.

 TypeScript Kamil Myśliwiec + OSS community MIT
Hono Ultrafast web framework that runs on any JS runtime.
▲ rising⚙
⚙ Backend
▲ rising gentle 2021

A tiny, ultrafast web framework with an Express-like API that runs on virtually any JavaScript runtime — Cloudflare Workers, Deno, Bun, Node, and other edge platforms — from a single codebase. It leans on Web Standard Request/Response objects, which is what makes it portable to edge runtimes that lack Node APIs.
3 use cases Edge APIs on Cloudflare Workers, Deno Deploy, or Bun. Show all
  • Edge APIs on Cloudflare Workers, Deno Deploy, or Bun.
  • Portable services you want to run on multiple runtimes.
  • Latency-sensitive endpoints close to the user.
4 features Runs on Workers, Deno, Bun, Node — one codebase. Show all
  • Runs on Workers, Deno, Bun, Node — one codebase.
  • Built on Web Standard Request/Response, not Node-only APIs.
  • Tiny footprint and a very fast router (RegExpRouter).
  • Typed middleware, RPC mode, and validators built in.

Being runtime-agnostic means you must avoid Node-only APIs (fs, process) if you want the edge targets, and each platform has its own bindings and deploy story. The ecosystem is younger than Express’s, so some integrations you’d take for granted aren’t there yet.

 TypeScript Yusuke Wada + OSS community MIT
Laravel PHP’s batteries-included, developer-happiness framework.
★ standard⚙
⚙ Backend
★ standard moderate 2011

The dominant full-stack PHP framework — opinionated and batteries-included, with the Eloquent ORM, Blade templating, routing, queues, auth scaffolding, and a deep first-party ecosystem (Breeze, Sanctum, Livewire, Forge). It aims to make common web tasks elegant rather than make you wire libraries together.
3 use cases Full-stack web apps and server-rendered sites in PHP. Show all
  • Full-stack web apps and server-rendered sites in PHP.
  • SaaS products needing auth, billing, queues, and admin fast.
  • Teams that value convention and a cohesive first-party ecosystem.
4 features Eloquent ORM with expressive Active Record models. Show all
  • Eloquent ORM with expressive Active Record models.
  • Blade templating and Artisan CLI scaffolding.
  • Built-in queues, scheduling, events, and broadcasting.
  • Cohesive first-party stack: Breeze, Sanctum, Livewire, Forge.

The convenience comes with “magic” — facades, service-container auto-resolution, and Eloquent’s Active Record hide a lot, which is productive until you need to debug or optimize it. Eloquent’s lazy loading makes N+1 query problems easy to write accidentally.

 PHP Taylor Otwell / Laravel LLC + OSS MIT
Django Python’s batteries-included framework with a killer admin.
★ standard⚙
⚙ Backend
★ standard moderate 2005

A mature, batteries-included Python web framework following a “model–template–view” pattern. It ships an ORM, an auto-generated admin interface, auth, migrations, forms, and security defaults out of the box — famous for letting you build a data-driven site fast without choosing a stack of libraries.
3 use cases Content- and data-heavy sites needing a real admin interf... Show all
  • Content- and data-heavy sites needing a real admin interface.
  • Full-stack Python web apps and server-rendered pages.
  • REST APIs via Django REST Framework on top of the ORM.
4 features Powerful ORM with migrations baked in. Show all
  • Powerful ORM with migrations baked in.
  • Auto-generated admin site from your models.
  • Built-in auth, forms, sessions, and security middleware.
  • Async views and a huge package ecosystem (DRF, Channels).

It’s opinionated and monolithic — great when your app fits the model-template-view mold, heavier than you want for a tiny JSON API (where FastAPI fits better). The synchronous ORM is the historical core; async support exists but isn’t as seamless as a from-scratch async framework.

 Python Django Software Foundation + OSS BSD-3-Clause
FastAPI Async Python APIs driven by type hints, with free OpenAPI docs.
▲ rising⚙
⚙ Backend
▲ rising gentle 2018

A modern, high-performance Python framework for building APIs, built on Starlette and Pydantic. You annotate function parameters with Python type hints and FastAPI uses them to validate requests, serialize responses, and generate interactive OpenAPI docs automatically — all async-first.
3 use cases Async JSON APIs and microservices in Python. Show all
  • Async JSON APIs and microservices in Python.
  • ML/data-science model serving with typed request bodies.
  • Any API where auto-generated OpenAPI docs save time.
4 features Type-hint-driven request validation via Pydantic. Show all
  • Type-hint-driven request validation via Pydantic.
  • Automatic interactive OpenAPI/Swagger documentation.
  • Async-first on the ASGI standard (Starlette under the hood).
  • Dependency-injection system for shared logic and auth.

“Fast to write” doesn’t include the data layer — FastAPI has no built-in ORM, so you bring SQLAlchemy/SQLModel and wire migrations yourself. Mixing sync and async code, or doing blocking I/O in an async route, quietly stalls the event loop.

 Python Sebastián Ramírez + OSS community MIT
tRPC End-to-end typesafe APIs for TypeScript — no schema, no codegen.
● mainstream⚙▦
⚙ Backend▦ Full-stack
● mainstream moderate 2020

A library for building end-to-end typesafe APIs in a TypeScript codebase. Unlike REST or GraphQL, there’s no schema language or code generation — the server’s procedure types flow directly to the client through TypeScript inference, so a backend change becomes a client-side type error instantly.
3 use cases Full-stack TypeScript monorepos sharing one type system. Show all
  • Full-stack TypeScript monorepos sharing one type system.
  • Next.js apps wanting typed server calls without REST boilerplate.
  • Teams that own both ends and want refactors to stay type-safe.
4 features No schema, no codegen — types inferred from the server. Show all
  • No schema, no codegen — types inferred from the server.
  • Autocomplete and compile-time errors across the client/server boundary.
  • Adapters for Next.js, Express, Fastify, and more.
  • Pairs with TanStack Query for client-side caching.

It’s TypeScript-to-TypeScript only — there’s no public, language-agnostic contract, so it’s a poor fit for third-party consumers, mobile teams on other stacks, or public APIs (reach for REST/GraphQL there). The magic also tightly couples client and server, which only works in a shared codebase.

 TypeScript Alex Johansson + OSS community MIT
GraphQL Yoga A batteries-included, spec-compliant GraphQL server.
● mainstream⚙
⚙ Backend
● mainstream moderate 2018

A fully-featured GraphQL server from The Guild, built on the GraphQL.js reference implementation. It is runtime-agnostic (Node, Bun, Deno, Workers) thanks to Web Standard Request/Response, ships sensible defaults — subscriptions, file uploads, and a built-in GraphiQL explorer — and plugs into the Envelop plugin ecosystem.
3 use cases Standing up a GraphQL API server with minimal config. Show all
  • Standing up a GraphQL API server with minimal config.
  • Graphs that need subscriptions, uploads, or the Envelop plugin system.
  • GraphQL endpoints on edge runtimes alongside Node.
4 features Spec-compliant on the GraphQL.js reference implementation. Show all
  • Spec-compliant on the GraphQL.js reference implementation.
  • Runtime-agnostic: Node, Bun, Deno, Cloudflare Workers.
  • Subscriptions, file uploads, and GraphiQL built in.
  • Extensible via the Envelop plugin ecosystem.

Yoga is the server — you still design the schema and write resolvers, and GraphQL’s own footguns (N+1 resolver queries needing DataLoader, query-depth and complexity limits to prevent abuse) are on you. For simple typed internal APIs, tRPC is often less ceremony.

 TypeScript The Guild + OSS community MIT
PostgreSQL The world’s most advanced open-source relational database.
★ standard▣
▣ Database
★ standard moderate 1996

The default open-source relational database for new projects — a mature, standards-compliant SQL engine known for correctness, extensibility, and a deep feature set: rich types (JSONB, arrays, ranges), full-text search, window functions, and an extension ecosystem (PostGIS, pgvector). Most modern ORMs and serverless platforms target it first.
3 use cases The default relational store for new web and SaaS backends. Show all
  • The default relational store for new web and SaaS backends.
  • Workloads mixing relational data with JSON or vector/geo queries.
  • Anything needing strong ACID guarantees and complex queries.
4 features Full ACID compliance and rich SQL (window functions, CTEs). Show all
  • Full ACID compliance and rich SQL (window functions, CTEs).
  • JSONB for schemaless data alongside relational tables.
  • Extensions: PostGIS (geo), pgvector (embeddings), and more.
  • MVCC concurrency and robust replication.

Connection-heavy: each connection is a process, so serverless functions that open connections per-invocation exhaust the server — you need a pooler (PgBouncer, or a platform like Neon/Supabase that bundles one). Tuning VACUUM and autovacuum on write-heavy tables is a real operational concern.

 C PostgreSQL Global Development Group PostgreSQL License
MySQL The ubiquitous open-source relational database.
★ standard▣
▣ Database
★ standard moderate 1995

One of the most widely deployed relational databases, the “M” in the classic LAMP stack and the default behind much of the PHP web. Owned by Oracle and dual-licensed (GPL plus a commercial license), with the community-driven fork MariaDB as a drop-in alternative. Reliable, fast on read-heavy workloads, and supported by every host and ORM.
3 use cases Classic LAMP / PHP web apps and WordPress sites. Show all
  • Classic LAMP / PHP web apps and WordPress sites.
  • Read-heavy applications with well-understood schemas.
  • Projects on hosts where MySQL is the default offering.
4 features ACID transactions via the InnoDB storage engine. Show all
  • ACID transactions via the InnoDB storage engine.
  • Mature replication and broad hosting support everywhere.
  • Pluggable storage engines (InnoDB, MyISAM).
  • MariaDB fork as a drop-in, fully open alternative.

Feature parity with Postgres lags in places — historically weaker support for advanced SQL, stricter SQL-mode quirks, and gotchas around default character sets (use utf8mb4, not the legacy utf8, for full Unicode). The dual GPL/commercial license matters if you embed or redistribute it.

 C++ Oracle Corporation GPL-2.0
SQLite A zero-config, embedded SQL database in a single file.
★ standard▣
▣ Database
★ standard gentle 2000

A self-contained, serverless, zero-configuration SQL database engine — the entire database is a single file on disk and the engine is a library linked into your app, with no separate process to run. It is the most widely deployed database in the world (every phone, browser, and OS ships it) and is increasingly used for production web apps at the edge.
3 use cases Embedded storage in mobile, desktop, and CLI apps. Show all
  • Embedded storage in mobile, desktop, and CLI apps.
  • Local development, tests, and prototypes — no server to run.
  • Edge / low-traffic web apps (often via Turso/libSQL or LiteFS).
4 features Entire database is one portable file; no server process. Show all
  • Entire database is one portable file; no server process.
  • Zero configuration — link the library and open a file.
  • Full transactional ACID even across crashes.
  • Tiny, public-domain, and embedded almost everywhere.

Single-writer by design — concurrent writes serialize, so it’s a poor fit for write-heavy, high-concurrency multi-user backends without a layer like libSQL/Turso. It’s also loosely typed by default (type affinity, not strict types) unless you opt into STRICT tables.

 C D. Richard Hipp / SQLite Consortium Public Domain
MongoDB The popular document database for flexible, JSON-like data.
● mainstream▣
▣ Database
● mainstream moderate 2009

A document-oriented NoSQL database that stores records as flexible, JSON-like BSON documents instead of rows in tables — so the schema can vary per document and nested data lives together. Popular for its developer-friendly model and horizontal scaling; its managed Atlas service is the common way to run it. Licensed under the source-available SSPL, not an OSI-approved open-source license.
3 use cases Apps with flexible or rapidly-evolving schemas. Show all
  • Apps with flexible or rapidly-evolving schemas.
  • Content, catalogs, and event data that fit a document shape.
  • Horizontally-scaled workloads via sharding (often on Atlas).
4 features Flexible JSON-like (BSON) documents, no fixed schema. Show all
  • Flexible JSON-like (BSON) documents, no fixed schema.
  • Aggregation pipeline for complex transformations.
  • Built-in sharding for horizontal scale and replica sets.
  • Managed Atlas service with search and vector search.

Schema flexibility is a double-edged sword — without discipline (or an ODM like Mongoose) data drifts into inconsistent shapes. Multi-document transactions exist but cost more than in a relational DB, and modeling relationships you’d join in SQL often means denormalizing. The SSPL license blocks offering MongoDB itself as a managed service.

 C++ MongoDB, Inc. SSPL
Redis Blazing-fast in-memory key-value store, cache, and message broker.
★ standard▣
▣ Database
★ standard moderate 2009

An in-memory data-structure store used as a cache, key-value database, and message broker. It keeps data in RAM (with optional persistence to disk) for sub-millisecond access, and offers rich types — strings, hashes, lists, sets, sorted sets, streams, and pub/sub. After a 2024 move to source-available terms, Redis 8 (2025) re-added the OSI-approved AGPLv3 as a license option.
3 use cases Caching layer in front of a slower primary database. Show all
  • Caching layer in front of a slower primary database.
  • Sessions, rate limiting, and ephemeral counters.
  • Job queues, pub/sub, leaderboards (sorted sets), and streams.
 —
4 features Sub-millisecond in-memory reads and writes. Show all
  • Sub-millisecond in-memory reads and writes.
  • Rich data types: hashes, lists, sets, sorted sets, streams.
  • Pub/sub and stream messaging primitives.
  • Optional persistence (RDB snapshots, AOF) and replication.

It’s memory-bound — your dataset must fit in RAM, and eviction policies decide what gets dropped when it’s full, so it’s usually a cache or secondary store, not your system of record. The 2024–2025 license churn (SSPL/RSALv2, then AGPLv3 re-added in Redis 8) spawned the Valkey fork; check which license your distro/cloud ships.

 C Redis Ltd. + OSS community AGPLv3 / RSALv2 / SSPL
Firebase Firestore Google’s serverless document database with realtime sync.
● mainstream▣
▣ Database
● mainstream gentle 2017

A fully-managed, serverless NoSQL document database from Google’s Firebase platform. Clients subscribe to documents and queries and receive realtime updates as data changes, with offline caching on mobile and web. Access control lives in declarative security rules rather than a server, making it popular for client-driven apps without a backend.
3 use cases Realtime apps — chat, collaboration, live dashboards. Show all
  • Realtime apps — chat, collaboration, live dashboards.
  • Mobile/web apps wanting offline sync with no server to run.
  • MVPs that lean on Firebase Auth, Storage, and Functions together.
4 features Realtime listeners push changes to clients instantly. Show all
  • Realtime listeners push changes to clients instantly.
  • Offline persistence and automatic sync on reconnect.
  • Declarative security rules instead of server-side authz.
  • Tight integration with Firebase Auth, Storage, and Functions.

It’s proprietary lock-in and the data model bends queries — no joins, no arbitrary WHERE/aggregation, every multi-field query needs a composite index, and you denormalize heavily. Billing is per document read/write, so naive realtime listeners or fan-out writes can run up a surprising bill.

 proprietary (Go/C++ internally) Google (Firebase / Google Cloud) proprietary
Supabase The open-source Firebase alternative, built on Postgres.
▲ rising▣⚙
▣ Database⚙ Backend
▲ rising gentle 2020

An open-source backend-as-a-service that bundles a full PostgreSQL database with auth, file storage, edge functions, and realtime subscriptions — positioned as a Firebase alternative, but on a real relational engine you can query with SQL and take with you. It auto-generates a REST and GraphQL API from your schema and enforces access with Postgres row-level security.
3 use cases Full app backends wanting Postgres plus auth, storage, an... Show all
  • Full app backends wanting Postgres plus auth, storage, and realtime.
  • Teams that want a Firebase-like DX without leaving SQL.
  • Projects that may later self-host the open-source stack.
4 features A real Postgres database, queryable in plain SQL. Show all
  • A real Postgres database, queryable in plain SQL.
  • Built-in auth, storage, edge functions, and realtime.
  • Auto-generated REST and GraphQL APIs from your schema.
  • Row-level security policies for client-direct access.

The client-direct model lives or dies by row-level security — forget to enable RLS on a table and it’s world-readable/writable. “Open-source” is true of the stack, but self-hosting the whole platform is non-trivial; most teams use the managed cloud and inherit its pricing.

 TypeScript / Elixir / Go Supabase, Inc. + OSS community Apache-2.0
PlanetScale Serverless MySQL on Vitess with database branching.
● mainstream▣
▣ Database
● mainstream moderate 2021

A managed, serverless MySQL-compatible database platform built on Vitess (the sharding layer that scaled YouTube). Its signature feature is Git-style database branching: spin off a branch, change the schema, and merge it back as a non-blocking, online deploy request. PlanetScale removed its free tier in April 2024, so it now starts around $39/month.
3 use cases MySQL apps that need horizontal scale via Vitess sharding. Show all
  • MySQL apps that need horizontal scale via Vitess sharding.
  • Teams wanting schema changes as reviewable, non-blocking deploys.
  • Production MySQL workloads with serverless connection handling.
4 features Git-style branching with online, non-blocking schema depl... Show all
  • Git-style branching with online, non-blocking schema deploys.
  • Built on Vitess for transparent horizontal sharding.
  • Serverless connection pooling friendly to edge/functions.
  • Insights and query analysis built in.

The free tier is gone (since April 2024), so it’s a paid service from the start — factor that against free-tier rivals. Because it’s Vitess, some MySQL features are constrained: foreign-key enforcement is limited and cross-shard transactions/joins don’t behave like single-node MySQL.

 Go (Vitess) PlanetScale, Inc. proprietary
Neon Serverless Postgres with instant database branching.
▲ rising▣
▣ Database
▲ rising gentle 2021

A serverless PostgreSQL platform that separates storage from compute, so databases scale to zero when idle and spin up on demand, and you can branch the entire database (data and schema) instantly like Git for development or preview environments. The core is Apache-2.0 licensed. Neon was acquired by Databricks in May 2025 (~$1B), which kept the free tier and lowered prices.
3 use cases Serverless and edge apps wanting Postgres that scales to ... Show all
  • Serverless and edge apps wanting Postgres that scales to zero.
  • Per-pull-request preview databases via instant branching.
  • Cost-sensitive projects with spiky or intermittent traffic.
4 features Separated storage/compute — scales to zero when idle. Show all
  • Separated storage/compute — scales to zero when idle.
  • Instant copy-on-write branching of the whole database.
  • Serverless driver works over HTTP/WebSocket from the edge.
  • Apache-2.0 core; standard Postgres wire protocol.

Scale-to-zero means a cold start — the first query after idle pays a wake-up latency, which matters for user-facing requests (keep a paid compute warm if it does). Long-lived pooled connections and very write-heavy steady workloads fit the serverless billing model less well than spiky ones.

 Rust Neon (Databricks) + OSS community Apache-2.0
Prisma The schema-first TypeScript ORM with end-to-end type safety.
★ standard⚙
⚙ Backend
★ standard gentle 2019

A schema-first ORM for Node.js and TypeScript: you describe your models in a schema.prisma file and Prisma generates a fully typed client plus SQL migrations. Prisma 7 (Nov 2025) removed the Rust query engine — the client is now pure TypeScript/WebAssembly, cutting bundle size ~85–90%, working on the edge, and starting cold far faster.
3 use cases TypeScript backends that want autocompleted, type-safe qu... Show all
  • TypeScript backends that want autocompleted, type-safe queries.
  • Teams who want declarative migrations from a single schema file.
  • Serverless and edge functions (post-v7, with no native binary).
4 features Single schema.prisma source of truth for models + migrati... Show all
  • Single schema.prisma source of truth for models + migrations.
  • Generated, fully typed client — autocomplete on every query.
  • Prisma Migrate for versioned schema changes; Prisma Studio GUI.
  • v7: pure TS/WASM engine — edge-compatible, smaller, faster cold starts.

Before v7 the Rust query engine shipped as a native binary that bloated bundles and broke on some edge/serverless runtimes — pin to v7+ if you target the edge. Long-running connection pools in serverless still need Prisma Accelerate or a pooler like PgBouncer to avoid exhausting connections.

 TypeScript Prisma Data, Inc. + OSS community Apache-2.0
Drizzle A lightweight, SQL-like TypeScript ORM built for the edge.
▲ rising⚙
⚙ Backend
▲ rising moderate 2022

A code-first, headless TypeScript ORM whose query API mirrors SQL — if you know SQL, you already know Drizzle. You declare your schema in TypeScript, ship a tiny zero-dependency runtime, and get full type inference, making it a favourite for serverless and edge deployments.
3 use cases Serverless and edge runtimes where bundle size and cold s... Show all
  • Serverless and edge runtimes where bundle size and cold starts matter.
  • Developers who want SQL-shaped queries with full type inference.
  • Projects that prefer schema-in-TypeScript over a separate DSL file.
4 features SQL-like query builder — thin abstraction, no hidden magic. Show all
  • SQL-like query builder — thin abstraction, no hidden magic.
  • Tiny, zero-dependency runtime; serverless/edge-friendly.
  • Schema declared in TypeScript with full inference.
  • drizzle-kit for migrations; Drizzle Studio for browsing data.

The SQL-like surface means less hand-holding than Prisma — you write more explicit joins and relational queries yourself. The relational query API and migration tooling have matured fast but still churn between minor versions, so read the changelog before upgrading.

 TypeScript Drizzle Team + OSS community Apache-2.0
TypeORM Decorator-based ORM with Active Record and Data Mapper patterns.
● mainstream⚙
⚙ Backend
● mainstream moderate 2016

A mature TypeScript/JavaScript ORM that maps classes to tables using decorators (@Entity, @Column). It supports both the Active Record and Data Mapper patterns and many SQL databases, and is the default ORM in the NestJS ecosystem — though its maintenance cadence has been uneven.
3 use cases NestJS apps, where TypeORM is the conventional data layer. Show all
  • NestJS apps, where TypeORM is the conventional data layer.
  • Teams who prefer class + decorator entity definitions.
  • Projects wanting a choice of Active Record or Data Mapper style.
4 features Decorator-driven entities (@Entity, @Column, @ManyToOne). Show all
  • Decorator-driven entities (@Entity, @Column, @ManyToOne).
  • Both Active Record and Data Mapper patterns supported.
  • Migrations, query builder, and broad SQL database support.
  • First-class integration with NestJS.

Maintenance has been famously stop-start, with long gaps between releases and a backlog of open issues. Decorators require reflect-metadata and specific tsconfig flags (experimentalDecorators, emitDecoratorMetadata), and the type safety is weaker than Prisma or Drizzle — many queries fall back to any.

 TypeScript TypeORM contributors (OSS) MIT
Sequelize The long-standing promise-based ORM for SQL databases.
● mainstream⚙
⚙ Backend
● mainstream moderate 2010

One of the oldest Node.js ORMs — a promise-based, model-driven library for Postgres, MySQL, MariaDB, SQLite, and SQL Server. Battle-tested and widely deployed, it predates the TypeScript-first wave and its typings, while improved, still feel bolted on rather than native.
3 use cases Established JavaScript codebases already standardized on ... Show all
  • Established JavaScript codebases already standardized on Sequelize.
  • Apps targeting multiple SQL dialects from one model layer.
  • Maintaining legacy Express services with existing models.
4 features Model definitions, associations, validations, and hooks. Show all
  • Model definitions, associations, validations, and hooks.
  • Supports Postgres, MySQL, MariaDB, SQLite, and SQL Server.
  • Migrations and seeders via the Sequelize CLI.
  • Transactions, eager/lazy loading, and raw query escape hatch.

TypeScript support is the weak spot — types are community-maintained and verbose, and many setups still type query results loosely. For greenfield TypeScript projects, Prisma or Drizzle give far stronger inference; reach for Sequelize mainly when a codebase already depends on it.

 JavaScript Sequelize contributors (OSS) MIT
Knex.js A SQL query builder, not a full ORM — you stay close to SQL.
● mainstream⚙
⚙ Backend
● mainstream gentle 2013

A SQL query builder (not an ORM) for Node.js: it builds and runs SQL across Postgres, MySQL, SQLite, and more via a fluent, chainable API, plus connection pooling and migrations. There’s no model or identity map — you get composable SQL without raw string concatenation.
3 use cases Apps that want SQL control without an ORM's abstraction. Show all
  • Apps that want SQL control without an ORM’s abstraction.
  • As the query layer underneath higher-level libraries (e.g. Objection.js).
  • Database migrations and seeds in plain Node scripts.
4 features Fluent, chainable query builder over many SQL dialects. Show all
  • Fluent, chainable query builder over many SQL dialects.
  • Built-in migrations, seeds, and connection pooling.
  • Raw SQL escape hatch when the builder isn’t enough.
  • No model layer — a thin abstraction close to the database.

It’s a query builder, so there’s no identity map, relations, or lazy loading — you manage those yourself. Result rows are largely untyped (any) unless you layer types manually, which is why type-conscious teams increasingly reach for Kysely or Drizzle instead.

 JavaScript Knex.js contributors (OSS) MIT
Mongoose The de-facto standard ODM for MongoDB and Node.js.
★ standard⚙
⚙ Backend
★ standard gentle 2010

The standard Object Document Mapper (ODM) for MongoDB — the document-store analogue of an ORM. It adds schemas, validation, middleware, and population (referenced-document joins) on top of MongoDB’s otherwise schemaless documents, giving structure to an unstructured store.
3 use cases Node.js apps using MongoDB that want schema validation an... Show all
  • Node.js apps using MongoDB that want schema validation and structure.
  • Modeling relationships between documents via population.
  • MERN/MEAN-stack backends needing middleware hooks on save/update.
4 features Schemas with type casting, validation, and defaults. Show all
  • Schemas with type casting, validation, and defaults.
  • Middleware (pre/post hooks) on document lifecycle events.
  • Population to resolve references across documents.
  • Plugins, virtuals, and a fluent query API.

Mongoose adds a schema layer over a schemaless database, which can fight MongoDB’s flexible-document strengths and adds overhead on hot paths. TypeScript typing of schemas is improving but historically clunky, and populate joins are easy to overuse, hurting performance.

 JavaScript Automattic + OSS community MIT
Vercel The frontend cloud — git-push deploys and the home of Next.js.
★ standard☁▦
☁ Infra▦ Full-stack
★ standard gentle 2015

A frontend-focused PaaS and the company behind Next.js. Connect a git repo and every push deploys to a global edge network with serverless and edge functions; every branch and pull request gets its own preview URL. Optimized for SSR and SSG frontends.
3 use cases Deploying Next.js, SvelteKit, Astro, or any modern fronte... Show all
  • Deploying Next.js, SvelteKit, Astro, or any modern frontend in seconds.
  • Per-branch preview deployments for reviewing changes.
  • Serverless and edge functions colocated with the frontend.
4 features Git-push deploys with automatic preview URLs per branch/PR. Show all
  • Git-push deploys with automatic preview URLs per branch/PR.
  • Global edge network plus serverless and edge functions.
  • First-class Next.js support (ISR, image optimization, RSC).
  • Built-in analytics, environment variables, and instant rollbacks.

The free Hobby tier is non-commercial — production apps need a paid plan. Bandwidth and serverless-function usage are metered, so high-traffic or heavy edge workloads can get expensive, and you’re somewhat locked into Vercel’s build conventions for the best Next.js features.

 — Vercel Inc. proprietary
Netlify The platform that popularized JAMstack git-push deploys.
★ standard☁▦
☁ Infra▦ Full-stack
★ standard gentle 2014

A frontend deployment platform that pioneered the JAMstack workflow: connect a git repo and each push builds and deploys to a global CDN. It bundles edge functions, serverless functions, form handling, identity, and deploy previews for static sites and SPAs.
3 use cases Static sites and SPAs deployed straight from a git push. Show all
  • Static sites and SPAs deployed straight from a git push.
  • JAMstack apps wanting forms, identity, and functions out of the box.
  • Deploy previews on every pull request.
4 features Git-push builds with deploy previews per branch/PR. Show all
  • Git-push builds with deploy previews per branch/PR.
  • Global CDN with instant cache invalidation and rollbacks.
  • Edge and serverless functions; built-in forms and identity.
  • Netlify CLI and a generous static-hosting free tier.

Build-minute and bandwidth quotas on lower tiers can bite busy sites, and serverless-function cold starts and execution limits apply. Its SSR framework support has historically trailed Vercel’s tight Next.js integration, though adapters close most of the gap.

 — Netlify, Inc. proprietary
Cloudflare Pages Static sites and functions on Cloudflare’s global edge.
● mainstream☁▦
☁ Infra▦ Full-stack
● mainstream gentle 2021

A JAMstack hosting platform that serves static sites and full-stack apps from Cloudflare’s global edge, with dynamic logic running on Cloudflare Workers. It git-deploys like Vercel and Netlify but runs everything on the same vast CDN and edge runtime that fronts a large share of the web.
3 use cases Static sites and SPAs served from a huge global edge netw... Show all
  • Static sites and SPAs served from a huge global edge network.
  • Full-stack apps whose backend runs on Cloudflare Workers.
  • Projects already using Cloudflare DNS, R2, D1, or KV.
4 features Git-push deploys with unlimited preview deployments. Show all
  • Git-push deploys with unlimited preview deployments.
  • Functions powered by Cloudflare Workers at the edge.
  • Tight integration with R2, D1, KV, and Durable Objects.
  • Generous free tier with unmetered static bandwidth.

Functions run on the Workers runtime, not full Node.js — some Node APIs and packages don’t work without the nodejs_compat flag, and there are bundle-size and CPU-time limits per request. Cloudflare also acquired VoidZero (the Vite team) in 2026, tightening its build-tooling story.

 — Cloudflare, Inc. proprietary
GitHub Pages Free static hosting served straight from a GitHub repo.
★ standard☁
☁ Infra
★ standard gentle 2008

Free static-site hosting from GitHub: point it at a repository or branch and it serves the files over a CDN with HTTPS and optional custom domains. It can build Jekyll sites automatically, or you can deploy any prebuilt SSG output via GitHub Actions — this very site runs on it.
3 use cases Project docs, personal blogs, and portfolios with zero ho... Show all
  • Project docs, personal blogs, and portfolios with zero hosting cost.
  • Jekyll sites built automatically from a repo.
  • Any static-site-generator output deployed via GitHub Actions.
4 features Free static hosting with HTTPS and custom-domain support. Show all
  • Free static hosting with HTTPS and custom-domain support.
  • Built-in Jekyll build, or deploy any SSG via Actions.
  • Served over a global CDN straight from a branch or artifact.
  • No servers, no config beyond a repo setting or workflow.

It’s static-only — no server-side code, databases, or serverless functions, so dynamic features need a separate backend. Soft usage limits apply (~1 GB site, ~100 GB/month bandwidth, ~10 builds/hour), and the built-in Jekyll runs a pinned, restricted plugin set — custom plugins need a Actions build instead.

 — GitHub (Microsoft) proprietary
AWS The hyperscale cloud — every infrastructure primitive, à la carte.
★ standard☁▦
☁ Infra▦ Full-stack
★ standard steep 2006

Amazon Web Services — the largest IaaS/PaaS cloud, offering hundreds of building-block services: S3 for storage, EC2 for VMs, Lambda for serverless, CloudFront as a CDN, RDS for databases, and Amplify for frontend hosting. Unmatched breadth and scale, at the cost of real complexity.
3 use cases Large-scale production systems needing fine-grained control. Show all
  • Large-scale production systems needing fine-grained control.
  • Serverless backends (Lambda + API Gateway + DynamoDB).
  • Hosting anything from a static S3 site to a Kubernetes cluster.
4 features Hundreds of services: S3, EC2, Lambda, CloudFront, RDS, D... Show all
  • Hundreds of services: S3, EC2, Lambda, CloudFront, RDS, DynamoDB.
  • Global regions and availability zones for scale and redundancy.
  • Fine-grained IAM permissions and VPC networking.
  • Amplify for git-push frontend + serverless backend hosting.

The breadth is the curse — IAM, VPCs, regions, and the sheer service count make the learning curve the steepest here. Per-second metered billing can surprise you (egress fees, idle resources), so set budgets and alerts. Most teams reach for a higher-level PaaS unless they truly need AWS’s reach.

 — Amazon proprietary
Render A modern Heroku — simple PaaS for web services and databases.
● mainstream☁▦
☁ Infra▦ Full-stack
● mainstream gentle 2019

A developer-friendly PaaS pitched as a modern Heroku: connect a repo and Render builds and runs web services, background workers, cron jobs, static sites, and managed Postgres or Redis. It handles TLS, deploys, and autoscaling so you don’t touch IaaS plumbing.
3 use cases Deploying a backend API + managed Postgres without DevOps... Show all
  • Deploying a backend API + managed Postgres without DevOps overhead.
  • Teams migrating off Heroku wanting a similar git-push workflow.
  • Background workers, cron jobs, and static sites in one place.
4 features Git-push deploys for web services, workers, and static si... Show all
  • Git-push deploys for web services, workers, and static sites.
  • Managed PostgreSQL and Redis with automatic backups.
  • Free TLS, autoscaling, and zero-downtime deploys.
  • Infrastructure-as-code via a render.yaml blueprint.

The free tier spins services down after inactivity, so the first request after an idle period suffers a cold-start delay. It’s simpler but less configurable than raw AWS, and pricing can climb once you scale instances or add managed databases.

 — Render proprietary
Fly.io Run containers and VMs close to your users, worldwide.
● mainstream☁▦
☁ Infra▦ Full-stack
● mainstream moderate 2020

A platform for running full applications — packaged as containers and booted as lightweight Firecracker VMs (Fly Machines) — in regions around the globe, so compute sits close to users. Unlike a static CDN, it runs your actual server processes and databases at the edge.
3 use cases Latency-sensitive apps deployed near users in multiple re... Show all
  • Latency-sensitive apps deployed near users in multiple regions.
  • Running any Dockerized app or stateful service globally.
  • Edge-deployed Postgres or full backend processes (not just functions).
4 features Deploy Docker containers as fast-booting micro-VMs (Fly M... Show all
  • Deploy Docker containers as fast-booting micro-VMs (Fly Machines).
  • Run app instances in many regions for low latency.
  • Persistent volumes and managed Postgres at the edge.
  • Anycast networking and a fly.toml config + flyctl CLI.

Multi-region brings real distributed-systems complexity — data replication, region routing, and consistency are on you. It’s more hands-on than a git-push PaaS, occasional platform reliability hiccups have been reported, and stateful volumes are pinned to a single region per volume.

 — Fly.io, Inc. proprietary
Railway Developer-friendly PaaS with usage-based pricing and instant deploys.
● mainstream☁▦
☁ Infra▦ Full-stack
● mainstream gentle 2020

A polished PaaS built for a smooth developer experience: connect a repo and Railway autodetects the stack, provisions databases, wires up environment variables, and deploys — all billed by actual usage rather than fixed instance tiers. Strong on visual service graphs and one-click templates.
3 use cases Quickly standing up a full app + database for side projec... Show all
  • Quickly standing up a full app + database for side projects or MVPs.
  • Teams wanting usage-based billing instead of fixed dyno tiers.
  • Spinning up Postgres, Redis, or MySQL alongside an app in clicks.
4 features Auto-detected builds (Nixpacks) or your own Dockerfile. Show all
  • Auto-detected builds (Nixpacks) or your own Dockerfile.
  • One-click managed Postgres, MySQL, Redis, and MongoDB.
  • Usage-based pricing metered to actual compute and bandwidth.
  • Visual service graph, env-var sharing, and PR environments.

Usage-based billing is flexible but can make costs hard to predict for always-on services; watch the metered meter on long-running workloads. Railway removed its perpetual free tier (now a trial credit), and as a smaller platform it has less regional reach than the hyperscalers.

 — Railway Corp. proprietary
Firebase Hosting Fast static & SPA hosting in Google’s Firebase suite.
★ standard☁
☁ Infra
★ standard gentle 2014

Google’s static and single-page-app hosting within the Firebase platform: it serves your build over a global CDN with automatic HTTPS and integrates with Cloud Functions or Cloud Run for dynamic routes. It slots naturally beside Firebase Auth, Firestore, and Storage for a batteries-included app backend.
3 use cases Hosting SPAs (React, Angular, Vue) alongside Firebase Aut... Show all
  • Hosting SPAs (React, Angular, Vue) alongside Firebase Auth + Firestore.
  • Static sites needing a CDN, HTTPS, and easy custom domains.
  • Dynamic routes proxied to Cloud Functions or Cloud Run.
4 features Global CDN with automatic HTTPS and atomic deploys/rollba... Show all
  • Global CDN with automatic HTTPS and atomic deploys/rollbacks.
  • Rewrites to Cloud Functions and Cloud Run for dynamic content.
  • Preview channels for sharing pre-release builds.
  • Tight integration with Firebase Auth, Firestore, and Storage.

Hosting itself is static — dynamic logic means wiring up Cloud Functions or Cloud Run, which adds cost and cold starts. You’re tied into Google’s ecosystem, and Spark (free) plan quotas on storage and bandwidth are modest, so busy sites move to the metered Blaze plan.

 — Google proprietary
Docker Package an app and its dependencies into a portable container.
★ standard🔧☁
🔧 Tooling☁ Infra
★ standard moderate 2013

The tool that made Linux containers mainstream — bundle your app, runtime, and dependencies into an image that runs identically on a laptop, CI/CD runner, or production server. A Dockerfile describes the build, the image is the artifact, and a container is a running instance. Docker Compose orchestrates multi-container local stacks.
3 use cases Reproducible dev environments — "works on my machine" bec... Show all
  • Reproducible dev environments — “works on my machine” becomes “works in the image”.
  • Packaging an app for deployment to any container host or orchestrator.
  • Spinning up databases and services locally via Compose.
4 features Dockerfile build → immutable, layered images. Show all
  • Dockerfile build → immutable, layered images.
  • Compose for multi-container local stacks.
  • OCI image format runs on any compliant runtime.
  • Huge public registry (Docker Hub) of base images.

Layer ordering makes or breaks build caching — copy package.json and install before copying source, or every code change reinstalls everything. Also note the licensing split: the Docker Engine/CLI are Apache-2.0, but Docker Desktop is proprietary and requires a paid subscription for larger companies (the daemon itself stays free).

 Go Docker, Inc. + OSS community Apache-2.0
Kubernetes Orchestrate containers across a cluster, declaratively.
★ standard☁
☁ Infra
★ standard steep 2014

The de-facto container orchestrator — you declare the desired state ("run 3 replicas of this image, expose it on this port") in YAML and the control loop continuously reconciles reality toward it: scheduling pods, restarting crashed ones, rolling out updates, and load-balancing. Born at Google, now stewarded by the CNCF.
3 use cases Running microservices at scale with self-healing and auto... Show all
  • Running microservices at scale with self-healing and autoscaling.
  • Multi-environment deploys with declarative, version-controlled config.
  • Workloads that outgrow a single host or a simple PaaS.
4 features Declarative desired-state reconciliation. Show all
  • Declarative desired-state reconciliation.
  • Self-healing, rolling updates, and horizontal autoscaling.
  • Service discovery and built-in load balancing.
  • Extensible via CRDs, operators, and Helm charts.

The steepest curve in this batch — pods, services, ingress, RBAC, and YAML sprawl are a lot before you ship anything. Don’t reach for it too early: a single container on a PaaS or VM is far simpler until you genuinely need multi-node scaling and self-healing.

 Go CNCF (originally Google) + OSS community Apache-2.0
GitHub Actions CI/CD baked into your GitHub repo, triggered by events.
★ standard🔧☁
🔧 Tooling☁ Infra
★ standard moderate 2019

GitHub’s native CI/CD — define workflows as YAML files in .github/workflows/ that run on repo events (push, pull request, release, schedule, manual dispatch). Jobs run on GitHub-hosted or self-hosted runners, and a large marketplace of reusable actions covers most build/test/deploy steps. This very site deploys through it.
3 use cases Building, testing, and linting on every pull request. Show all
  • Building, testing, and linting on every pull request.
  • Deploying to GitHub Pages, cloud hosts, or a registry on merge.
  • Scheduled jobs (cron) and manual workflow_dispatch runs.
4 features YAML workflows triggered by repo events. Show all
  • YAML workflows triggered by repo events.
  • Marketplace of reusable, versioned actions.
  • GitHub-hosted and self-hosted runners.
  • Matrix builds, secrets, environments, and concurrency groups.

It’s a proprietary platform locked to GitHub — workflows aren’t portable to other hosts. Pin third-party actions to a full commit SHA (not a mutable tag) as a supply-chain safeguard, and watch minute-based billing on private repos with heavy matrix builds.

 YAML (workflows); runners in Go/TypeScript GitHub (Microsoft) proprietary
GitLab CI/CD Pipelines defined in .gitlab-ci.yml, built into the platform.
● mainstream🔧☁
🔧 Tooling☁ Infra
● mainstream moderate 2015

GitLab’s integrated CI/CD — a single .gitlab-ci.yml at the repo root defines stages and jobs that run on GitLab Runners. Tightly woven into the rest of the GitLab DevOps platform (issues, registry, environments, review apps), so the pipeline, the code, and the deploy all live in one place.
3 use cases End-to-end DevOps on a single self-hostable platform. Show all
  • End-to-end DevOps on a single self-hostable platform.
  • Pipelines with stages, manual gates, and environment deploys.
  • Teams wanting CI, registry, and issue tracking in one tool.
4 features Single .gitlab-ci.yml with stages and jobs. Show all
  • Single .gitlab-ci.yml with stages and jobs.
  • Self-hosted or GitLab-hosted runners.
  • Built-in container registry, environments, and review apps.
  • Includes, templates, and parent-child pipelines for reuse.

Open-core: the MIT-licensed Community Edition covers the basics, but a lot of CI/CD niceties (advanced security scanning, multiple approvers, some compliance controls) sit behind the proprietary paid tiers. Self-managed runners need real maintenance, and pipeline YAML grows complex fast on big monorepos.

 Ruby/Go (platform); YAML (pipelines) GitLab Inc. open-core (MIT CE + proprietary)
Terraform Provision cloud infrastructure as declarative, versioned code.
★ standard🔧☁
🔧 Tooling☁ Infra
★ standard moderate 2014

The dominant infrastructure-as-code tool — declare cloud resources (servers, networks, IaaS buckets, DNS, databases) in HCL, and Terraform computes a plan and applies it, tracking what exists in a state file. Provider plugins cover AWS, GCP, Azure, Cloudflare, and hundreds more.
3 use cases Reproducible, reviewable provisioning of cloud infrastruc... Show all
  • Reproducible, reviewable provisioning of cloud infrastructure.
  • Multi-environment (dev/staging/prod) parity from one codebase.
  • Managing DNS, networking, and managed services as code.
4 features Declarative HCL with plan/apply diffing. Show all
  • Declarative HCL with plan/apply diffing.
  • State file tracks managed resources.
  • Hundreds of providers via a plugin registry.
  • Modules for reusable, composable infrastructure.

No longer open source: HashiCorp relicensed Terraform from MPL-2.0 to the Business Source License (BSL 1.1, source-available) in August 2023, which spawned the community OpenTofu fork (still MPL-2.0) — choose deliberately. Operationally, the state file is sensitive and must be stored remotely with locking, or concurrent applies corrupt it. (HashiCorp was acquired by IBM in 2024.)

 Go HashiCorp (IBM) BSL 1.1
Ansible Agentless configuration management via YAML playbooks.
● mainstream🔧☁
🔧 Tooling☁ Infra
● mainstream moderate 2012

An agentless automation tool — describe the desired state of your servers in YAML "playbooks" and Ansible connects over plain SSH to apply them, no agent to install on targets. Idempotent modules mean re-running a playbook only changes what’s drifted, making it a staple for config management, app deployment, and orchestration.
3 use cases Configuring and patching fleets of servers consistently. Show all
  • Configuring and patching fleets of servers consistently.
  • App deployment and release orchestration over SSH.
  • One-off ad-hoc commands across many hosts.
4 features Agentless — runs over SSH, nothing to install on targets. Show all
  • Agentless — runs over SSH, nothing to install on targets.
  • Idempotent modules; re-runs only fix drift.
  • YAML playbooks and reusable roles.
  • Ansible Galaxy registry of community roles/collections.

Great for configuration, awkward for provisioning — pair it with Terraform rather than fighting to create cloud infrastructure from playbooks. Large playbooks run slowly (SSH per task, per host), and "idempotent" only holds if you use proper modules instead of raw shell/command tasks.

 Python Red Hat (IBM) + OSS community GPL-3.0
Nginx High-performance web server, reverse proxy, and load balancer.
★ standard☁
☁ Infra
★ standard moderate 2004

An event-driven web server renowned for serving static files and acting as a reverse proxy / load balancer in front of application servers. Its low memory footprint under high concurrency made it the standard front door for web apps — terminating TLS, routing requests, caching, and fronting upstreams (it also powers many a CDN edge).
3 use cases Serving static assets and SPA builds efficiently. Show all
  • Serving static assets and SPA builds efficiently.
  • Reverse-proxying and load-balancing app servers (Node, PHP-FPM, etc.).
  • TLS termination, caching, and rate limiting at the edge.
4 features Event-driven architecture — high concurrency, low memory. Show all
  • Event-driven architecture — high concurrency, low memory.
  • Reverse proxy, load balancer, and TLS terminator.
  • Static file serving and response caching.
  • Config-driven routing with server / location blocks.

The config language is its own DSL with sharp edges — location matching precedence, trailing-slash behavior on proxy_pass, and try_files ordering trip up newcomers. Reload (nginx -s reload) instead of restart to apply changes without dropping connections. F5 owns the project today.

 C F5, Inc. + OSS community BSD-2-Clause
Jenkins The veteran self-hosted CI server, extensible to a fault.
▼ legacy🔧☁
🔧 Tooling☁ Infra
▼ legacy steep 2011

The original open-source automation server — a self-hosted CI/CD engine driven by a vast plugin ecosystem and "Pipeline as code" via a Jenkinsfile (Groovy). Predates the cloud-native runners and remains entrenched in enterprises, though newer teams usually reach for GitHub Actions or GitLab CI instead.
3 use cases Self-hosted CI/CD where data must stay on-prem. Show all
  • Self-hosted CI/CD where data must stay on-prem.
  • Legacy enterprise pipelines already built on Jenkins.
  • Highly customized builds needing a specific plugin.
4 features Pipeline as code via a Groovy Jenkinsfile. Show all
  • Pipeline as code via a Groovy Jenkinsfile.
  • Thousands of plugins for almost any integration.
  • Distributed builds across controller + agents.
  • Fully self-hosted — no vendor lock-in.

Powerful but high-maintenance — you own the server, the agents, the upgrades, and a sprawling plugin set whose interdependencies and CVEs need constant tending. The plugin-heavy model that was once its strength now reads as legacy next to managed cloud CI; pick it deliberately, usually for on-prem constraints.

 Java Jenkins community (CDF) MIT
Git The distributed version control system everyone uses.
★ standard🔧
🔧 Tooling
★ standard moderate 2005

The distributed version-control standard — every clone is a full repository with complete history, so branching, committing, and diffing are local and fast. Created by Linus Torvalds to manage Linux kernel development, it’s now the substrate beneath essentially all modern code hosting and CI/CD.
3 use cases Tracking history and collaborating on virtually any codeb... Show all
  • Tracking history and collaborating on virtually any codebase.
  • Branch-per-feature workflows and pull/merge requests.
  • The foundation every hosting platform and CI pipeline builds on.
4 features Distributed — every clone has the full history. Show all
  • Distributed — every clone has the full history.
  • Cheap, fast local branching and merging.
  • Content-addressed, integrity-checked object store (SHA hashes).
  • Staging area for crafting precise commits.

The mental model — staging area, detached HEAD, the difference between merge, rebase, and reset — is genuinely hard, and the CLI’s terminology is famously inconsistent. Force-pushing a shared branch (push --force) rewrites history others depend on; prefer --force-with-lease and never rewrite main.

 C Git community (Junio Hamano, maintainer) GPL-2.0
GitHub The dominant code-hosting and collaboration platform.
★ standard🔧☁
🔧 Tooling☁ Infra
★ standard gentle 2008

The largest code-hosting platform — Git repositories plus the social and collaboration layer on top: pull requests, code review, issues, Actions CI/CD, Packages, Pages, and now Copilot. Its network effects make it the default home for open source and a huge share of private development. (Microsoft owns it.)
3 use cases Hosting public and private Git repos with code review. Show all
  • Hosting public and private Git repos with code review.
  • Open-source collaboration via forks and pull requests.
  • Issues, project boards, Actions CI/CD, and Pages hosting.
4 features Pull requests with inline review and required checks. Show all
  • Pull requests with inline review and required checks.
  • Issues, Discussions, and project boards.
  • Built-in CI/CD (Actions), Packages, and Pages.
  • The largest open-source community and network effect.

It’s a proprietary, centralized service — convenient, but it means trusting a single vendor with your code, CI, and issues. Free private repos are generous, yet advanced security and admin features sit in paid tiers, and the network effect creates real lock-in around issues, PRs, and Actions that aren’t portable.

 Ruby / Go (platform) GitHub (Microsoft) proprietary
GitLab An all-in-one DevOps platform with built-in CI/CD.
● mainstream🔧☁
🔧 Tooling☁ Infra
● mainstream moderate 2011

A single DevOps platform spanning the whole lifecycle — Git hosting, code review (merge requests), issues, a container registry, security scanning, and tightly integrated CI/CD. Its big differentiator is being self-hostable: the open-core Community Edition can run entirely on your own infrastructure.
3 use cases Self-hosted Git + CI/CD where data sovereignty matters. Show all
  • Self-hosted Git + CI/CD where data sovereignty matters.
  • End-to-end DevOps (plan → code → build → deploy) in one tool.
  • Teams wanting an integrated registry and security scanning.
4 features Merge requests with built-in review and CI gates. Show all
  • Merge requests with built-in review and CI gates.
  • Integrated CI/CD (.gitlab-ci.yml) and container registry.
  • Self-hostable open-core Community Edition.
  • Issues, epics, and DevOps lifecycle tooling in one place.

Open-core: the MIT Community Edition is real, but many enterprise features (advanced security, compliance, multiple MR approvers) require the paid tiers. Self-hosting GitLab is resource-hungry and operationally heavy — budget for the RAM and the upgrade cadence before committing.

 Ruby / Go GitLab Inc. + OSS community open-core (MIT CE + proprietary)
Bitbucket Atlassian’s Git hosting, tight with Jira.
● mainstream🔧☁
🔧 Tooling☁ Infra
● mainstream gentle 2008

Atlassian’s code-hosting platform — Git repositories with pull requests and Bitbucket Pipelines CI/CD, but its real draw is deep integration with the rest of the Atlassian suite (Jira, Confluence, Trello). Most common in organizations already standardized on Jira.
3 use cases Teams already on Jira/Confluence wanting native integration. Show all
  • Teams already on Jira/Confluence wanting native integration.
  • Private Git hosting with built-in Pipelines CI/CD.
  • Enterprise Atlassian shops standardizing their toolchain.
4 features Native Jira and Confluence integration. Show all
  • Native Jira and Confluence integration.
  • Pull requests with inline code review.
  • Bitbucket Pipelines for in-platform CI/CD.
  • Cloud and self-managed (Data Center) options.

It’s proprietary and most compelling only if you’re already in the Atlassian ecosystem — its open-source community is far smaller than GitHub’s. Atlassian also retired Mercurial support in 2020, so Bitbucket is Git-only now, and its market momentum has cooled relative to GitHub and GitLab.

 Java / proprietary Atlassian proprietary
GitHub CLI Drive GitHub — PRs, issues, repos — from the terminal.
● mainstream🔧
🔧 Tooling
● mainstream gentle 2020

The official command-line tool (gh) for GitHub — manage pull requests, issues, releases, repositories, and Actions runs without leaving the terminal. It wraps the GitHub API with ergonomic commands and supports scripting and an extension system, making it a staple in automation and CI scripts (this site’s deploy tooling uses it).
3 use cases Opening, reviewing, and merging PRs from the terminal. Show all
  • Opening, reviewing, and merging PRs from the terminal.
  • Scripting GitHub workflows in CI (creating PRs, releases).
  • Cloning, forking, and managing repos without the web UI.
4 features PR, issue, release, and repo management from the shell. Show all
  • PR, issue, release, and repo management from the shell.
  • Authenticated wrapper over the GitHub API (gh api).
  • Extension system for custom commands.
  • Scriptable — ideal inside Actions and automation.

It’s GitHub-only — gh doesn’t talk to GitLab or Bitbucket (use glab for GitLab). In CI it needs an authenticated token with the right scopes, and the default GITHUB_TOKEN sometimes lacks permissions (e.g. creating PRs that trigger further workflows), so reach for a PAT when automation gets ambitious.

 Go GitHub (Microsoft) MIT
Mercurial A distributed VCS that Git largely eclipsed.
▼ legacy🔧
🔧 Tooling
▼ legacy moderate 2005

A distributed version-control system born the same year as Git, with a reputation for a cleaner, more consistent command set (hg). It powered major projects (Mozilla, parts of Facebook) and still survives at some large shops, but Git’s network effect — especially via GitHub — left it a niche choice today.
3 use cases Maintaining legacy repositories already on Mercurial. Show all
  • Maintaining legacy repositories already on Mercurial.
  • Teams that prefer its simpler, more uniform CLI to Git’s.
  • Very large monorepos where its scaling extensions shine.
4 features Distributed model with full local history (like Git). Show all
  • Distributed model with full local history (like Git).
  • More consistent, approachable command set than Git.
  • Extensible via a Python plugin system.
  • Scales to very large repos with extensions (e.g. at Meta).

The ecosystem has shrunk dramatically — GitHub dropped Mercurial support and Bitbucket removed it entirely in 2020, so hosting and tooling options are thin. For new projects, Git is the pragmatic default; pick hg only for an existing Mercurial codebase or a deliberate preference.

 Python Mercurial community GPL-2.0
Vitest The Vite-native test runner — Jest’s API, a fraction of the wait.
● mainstream🔧
🔧 Tooling
● mainstream gentle 2021

A blazing-fast unit-test framework built on top of Vite, so it reuses your app’s existing config, transforms, and ESM handling instead of duplicating them. The API is intentionally Jest-compatible (describe, it, expect), so most Jest suites migrate with little more than a config swap — but you get instant HMR-style watch mode and native TypeScript out of the box.
3 use cases Unit and component tests in any Vite-based project (React... Show all
  • Unit and component tests in any Vite-based project (React, Vue, Svelte, Solid).
  • Fast watch-mode TDD with instant re-runs on save.
  • Migrating a slow Jest suite to a faster, ESM-native runner.
4 features Shares the project's Vite config — no separate transform ... Show all
  • Shares the project’s Vite config — no separate transform pipeline.
  • Jest-compatible API and assertions for easy migration.
  • Native ESM + TypeScript, no Babel transpile step required.
  • Watch mode with smart re-runs, plus a browser-mode for real-DOM tests.

It’s Jest-compatible, not Jest — globals are off by default (enable globals: true or import from vitest), and module mocking (vi.mock) hoists differently than Jest’s jest.mock. Suites leaning on Jest internals or exotic transforms can need real porting work.

 TypeScript Vitest team (VoidZero, now Cloudflare) MIT
Jest The long-reigning batteries-included JS test framework.
★ standard🔧
🔧 Tooling
★ standard gentle 2014

The framework that made testing JavaScript pleasant — a zero-config runner with built-in assertions, mocking, snapshot testing, and parallel execution all in one package. For years it was the default for React and most of the Node ecosystem; it now uses a Babel transpile step to run modern syntax, which is part of why ESM-native runners feel faster.
3 use cases Unit and integration tests for Node and React codebases. Show all
  • Unit and integration tests for Node and React codebases.
  • Snapshot testing of serialized output and component trees.
  • Mature projects already standardized on the Jest API.
4 features All-in-one: runner, assertions, mocks, and snapshots. Show all
  • All-in-one: runner, assertions, mocks, and snapshots.
  • Parallel test execution across worker processes.
  • Rich snapshot and inline-snapshot testing.
  • Huge ecosystem of presets and matchers.

ESM support is still a sore spot — Jest historically assumed CJS and needs Babel or experimental flags to run native modules, and its global JSDOM environment is slower to spin up than Vite-based runners. Many new Vite projects pick Vitest instead.

 JavaScript OpenJS Foundation (originally Meta) MIT
Playwright Cross-browser end-to-end testing that actually stays green.
● mainstream🔧
🔧 Tooling
● mainstream moderate 2020

Microsoft’s browser automation and end-to-end testing framework that drives Chromium, Firefox, and WebKit through one API. Auto-waiting on elements, network interception, and test isolation per browser context kill most of the flakiness that plagued older E2E tools, and a code generator + trace viewer make writing and debugging tests fast.
3 use cases End-to-end testing of web apps across all three browser e... Show all
  • End-to-end testing of web apps across all three browser engines.
  • Cross-browser regression and visual testing in CI.
  • Scripted browser automation and scraping.
4 features One API across Chromium, Firefox, and WebKit. Show all
  • One API across Chromium, Firefox, and WebKit.
  • Auto-waiting and web-first assertions reduce flaky tests.
  • Codegen recorder + trace viewer for debugging.
  • Parallel execution with isolated browser contexts.

The browser binaries are a heavyweight install (npx playwright install) and CI images balloon accordingly. And like all E2E testing it’s slower and more brittle than unit tests — keep the E2E layer thin and push logic coverage down into unit tests.

 TypeScript Microsoft + OSS community Apache-2.0
Cypress End-to-end testing with a developer experience people love.
● mainstream🔧
🔧 Tooling
● mainstream gentle 2017

A browser E2E testing tool famous for its developer experience — tests run inside a live browser with a time-travel UI that lets you step through every command and see the app at each point. It auto-waits and retries assertions, and bundles its own runner, assertion library, and dashboard.
3 use cases End-to-end and integration testing with interactive debug... Show all
  • End-to-end and integration testing with interactive debugging.
  • Component testing for React, Vue, and Angular in a real browser.
  • Teams that value a polished test-authoring experience.
4 features Time-travel debugging — snapshots of every command step. Show all
  • Time-travel debugging — snapshots of every command step.
  • Automatic waiting and retry-ability on assertions.
  • Built-in test runner, assertions, and mocking.
  • Component-testing mode alongside full E2E.

Historically single-browser (Chromium-family) and same-origin bound — its architecture runs inside the browser, which limits multi-tab and cross-origin flows that Playwright handles natively. Many teams that need true cross-browser coverage have shifted to Playwright.

 JavaScript Cypress.io + OSS community MIT
Testing Library Test your UI the way users actually use it.
★ standard🔧
🔧 Tooling
★ standard gentle 2018

A family of lightweight DOM-testing utilities (React Testing Library, Vue Testing Library, and friends) built on one guiding principle: query the DOM by what a user sees — roles, labels, text — not by implementation details like CSS classes or component internals. It’s not a runner; it plugs into Vitest or Jest.
3 use cases Accessible, user-centric component tests for React/Vue/Sv... Show all
  • Accessible, user-centric component tests for React/Vue/Svelte.
  • Avoiding brittle tests coupled to internal markup or class names.
  • Encouraging accessibility-friendly markup via role-based queries.
4 features Queries by role, label, and text — not by CSS selectors. Show all
  • Queries by role, label, and text — not by CSS selectors.
  • Encourages accessible markup as a side-effect.
  • Runner-agnostic — works with Vitest or Jest.
  • user-event companion library for realistic interactions.

It’s a query layer, not a test runner — you still need Vitest or Jest plus JSDOM underneath. The philosophy bites if you reach for container.querySelector or test internal state; the library deliberately makes implementation-detail testing awkward.

 JavaScript Testing Library team + OSS community MIT
ESLint The pluggable linter that keeps JS/TS honest.
★ standard🔧
🔧 Tooling
★ standard moderate 2013

The de-facto standard linter for JavaScript and TypeScript — it statically analyzes code to catch bugs (unused vars, unreachable code, bad API usage) and enforce style and best-practice rules. Everything is a plugin, so frameworks ship their own rule sets; the modern flat-config format (eslint.config.js) is now the default.
3 use cases Catching bugs and enforcing conventions across a JS/TS co... Show all
  • Catching bugs and enforcing conventions across a JS/TS codebase.
  • Framework-specific rules (React hooks, import order, a11y).
  • Pre-commit and CI gates that block bad patterns from merging.
4 features Pluggable rule architecture with thousands of community r... Show all
  • Pluggable rule architecture with thousands of community rules.
  • Flat config (eslint.config.js) is the modern default.
  • Autofix for many rules (--fix).
  • TypeScript support via typescript-eslint.

The flat-config migration (ESLint 9) broke a lot of older .eslintrc setups and plugins — config examples online are split between the two formats. Don’t make ESLint enforce formatting (indentation, quotes); hand that to Prettier and let ESLint focus on code-quality rules.

 JavaScript OpenJS Foundation + OSS community MIT
Prettier Opinionated formatting that ends the whitespace wars.
★ standard🔧
🔧 Tooling
★ standard gentle 2017

An opinionated code formatter that reprints your code from its AST to a single consistent style — it ignores how you typed it and enforces uniform quotes, spacing, and line-wrapping. By design it has very few options, so teams stop arguing about style and just run it on save and in CI.
3 use cases Auto-formatting JS/TS/CSS/HTML/Markdown to a single house... Show all
  • Auto-formatting JS/TS/CSS/HTML/Markdown to a single house style.
  • Eliminating style debates in code review entirely.
  • Format-on-save in the editor plus a CI format check.
4 features Opinionated — minimal config, one canonical output. Show all
  • Opinionated — minimal config, one canonical output.
  • Formats JS, TS, CSS, HTML, JSON, Markdown, YAML, and more.
  • Editor integrations for format-on-save.
  • Pairs with ESLint via eslint-config-prettier.

Its few-options philosophy is a feature, not a bug — if you fight it over trivial style preferences you’ll lose. Run eslint-config-prettier so ESLint’s stylistic rules don’t conflict with Prettier’s output, or the two will undo each other.

 JavaScript Prettier team + OSS community MIT
TypeScript (tsc) The type-checker as a quality gate — tsc --noEmit.
★ standard🔧{ }
🔧 Tooling{ } Language
★ standard moderate 2012

The TypeScript compiler isn’t just a transpiler — run as tsc --noEmit it becomes a powerful static-analysis gate that catches whole classes of bugs (null access, wrong argument types, typos in property names) before code runs, with no output files. In modern stacks a tool like Vite or esbuild handles the transpile, leaving tsc to do pure type-checking in CI.
3 use cases CI type-check gate (tsc --noEmit) separate from bundling. Show all
  • CI type-check gate (tsc --noEmit) separate from bundling.
  • Catching type errors before runtime across a whole codebase.
  • Generating .d.ts declaration files for published libraries.
4 features Whole-program type checking with --noEmit for a pure gate. Show all
  • Whole-program type checking with --noEmit for a pure gate.
  • Declaration-file (.d.ts) emission for libraries.
  • Incremental and project-references builds for monorepos.
  • TypeScript 7 (“Corsa”) is a native Go port targeting ~10x speed.

On large codebases the classic JS-based tsc is slow, which is why teams split bundling (fast, by esbuild/Vite) from type-checking (tsc --noEmit, in CI). The Go-native rewrite shipping as TypeScript 7 targets roughly a 10x speedup; the preview is the @typescript/native-preview (tsgo) package.

 TypeScript / Go Microsoft + OSS community Apache-2.0
Storybook A workshop for building and testing UI components in isolation.
● mainstream🔧
🔧 Tooling
● mainstream moderate 2016

A development environment that renders your UI components in isolation, outside the app, so you can build, document, and test each one across its states (“stories”). It doubles as living design-system documentation and a base for visual-regression and interaction testing, working with React, Vue, Svelte, Angular, and Web Components.
3 use cases Building and reviewing components in isolation from the app. Show all
  • Building and reviewing components in isolation from the app.
  • Living design-system and component documentation.
  • Visual-regression and interaction testing of UI states.
4 features Renders components in isolation across all their states. Show all
  • Renders components in isolation across all their states.
  • Auto-generated docs from stories and component types.
  • Interaction + visual-regression testing via addons.
  • Framework-agnostic — React, Vue, Svelte, Angular, Web Components.

It’s a second build to configure and maintain — addons, framework presets, and major-version upgrades all carry overhead, and large story sets get slow. Keep stories close to components and lean on the Vite builder to keep startup fast.

 TypeScript Storybook team + OSS community MIT
npm The default package manager that ships with Node.
★ standard🔧
🔧 Tooling
★ standard gentle 2010

Node.js’s built-in package manager and the original gateway to the JavaScript ecosystem. It reads package.json, resolves a dependency tree into a flat node_modules, writes a package-lock.json for reproducible installs, and runs your scripts (npm run …). It’s the baseline every other JS package manager is measured against.
3 use cases Default dependency management for any Node/JS project. Show all
  • Default dependency management for any Node/JS project.
  • Running project scripts and publishing packages to the registry.
  • Lowest-friction choice when no special speed/disk needs exist.
4 features Ships with Node — zero extra install. Show all
  • Ships with Node — zero extra install.
  • Flat node_modules with package-lock.json for reproducibility.
  • Workspaces for basic monorepo support.
  • npx for running package binaries without installing them.

The flat node_modules is non-deterministic in layout and permissive — it lets you import packages you never declared (phantom dependencies), which breaks when a manager like pnpm enforces strictness. It’s also the slowest and most disk-hungry of the major managers on large installs.

 JavaScript npm, Inc. (GitHub / Microsoft) Artistic-2.0
pnpm Fast, disk-efficient, and strict about your dependency tree.
● mainstream🔧
🔧 Tooling
● mainstream gentle 2017

A drop-in npm alternative that stores every package version once in a global content-addressed store and hard-links it into each project’s node_modules, so ten projects sharing a dependency cost the disk space of one. Its non-flat layout is strict — you can only import what you actually declared — which kills phantom-dependency bugs and makes it a favorite for the monorepo crowd.
3 use cases Monorepos and machines with many projects (huge disk savi... Show all
  • Monorepos and machines with many projects (huge disk savings).
  • Teams that want a strict, phantom-dependency-free node_modules.
  • Faster CI installs than npm or classic Yarn.
4 features Content-addressed global store + hard links — install onc... Show all
  • Content-addressed global store + hard links — install once, reuse everywhere.
  • Strict, symlinked node_modules — no phantom dependencies.
  • First-class workspaces for monorepos.
  • Compatible with the npm registry and package.json scripts.

The symlinked, non-flat layout occasionally trips tooling that assumes a flat node_modules or resolves modules by walking the real filesystem path — a few legacy packages need a node-linker=hoisted escape hatch. The strictness that catches phantom deps can also surface latent bugs the day you switch from npm.

 TypeScript pnpm team + OSS community MIT
Yarn The manager that pushed npm to get faster and deterministic.
● mainstream🔧
🔧 Tooling
● mainstream moderate 2016

A package manager born at Meta to fix early npm’s speed and determinism problems — it introduced lock files and parallel installs that npm later adopted. Yarn Classic (v1) behaves like npm; Yarn Berry (v2+) is a rewrite with Plug’n’Play, which skips node_modules entirely and resolves modules from a single zipped cache.
3 use cases Projects already standardized on Yarn workspaces. Show all
  • Projects already standardized on Yarn workspaces.
  • Plug’n’Play setups that want to eliminate node_modules.
  • Teams wanting plugin-extensible install behavior.
4 features Deterministic lock file and parallel installs. Show all
  • Deterministic lock file and parallel installs.
  • Workspaces for monorepos (Classic and Berry).
  • Yarn Berry’s Plug’n’Play removes node_modules.
  • Plugin architecture for extending the CLI.

Yarn Classic (v1) and Yarn Berry (v2+) are almost two different tools — Berry’s Plug’n’Play breaks packages that expect a real node_modules, so many Berry users fall back to the node-modules linker. Pick a major version deliberately; mixing advice from both eras causes confusion.

 TypeScript Yarn team + OSS community (originally Meta) BSD-2-Clause
Bun (package manager) bun install — an absurdly fast npm-compatible installer.
▲ rising🔧
🔧 Tooling
▲ rising gentle 2022

The package-manager half of the Bun runtime — bun install reads your existing package.json and installs from the npm registry, but does it many times faster than npm or Yarn thanks to a native (Zig) implementation and an aggressive global cache. It’s a drop-in installer you can adopt even if the rest of your stack still runs on Node.
3 use cases Drastically faster dependency installs in dev and CI. Show all
  • Drastically faster dependency installs in dev and CI.
  • Drop-in bun install replacement on existing Node projects.
  • Greenfield projects already using the Bun runtime end-to-end.
4 features Native (Zig) installer — dramatically faster than npm/Yarn. Show all
  • Native (Zig) installer — dramatically faster than npm/Yarn.
  • Reads package.json + works with the npm registry.
  • Global cache with hard links for fast, deduplicated installs.
  • Built into the Bun runtime alongside its bundler and test runner.

The installer is the most battle-tested part of Bun, but edge cases in lifecycle scripts, peer-dependency resolution, and lockfile interop with other managers still surface. Bun was acquired by Anthropic in December 2025 and stays MIT-licensed; the project remains young relative to npm and pnpm.

 Zig Bun team (Anthropic) MIT
npm registry The public warehouse — 3M+ packages every JS manager pulls from.
★ standard🔧☁
🔧 Tooling☁ Infra
★ standard gentle 2010

The public registry at registry.npmjs.org that hosts over three million JavaScript packages — the default source that npm, pnpm, Yarn, and Bun all download from. It’s a hosted service (not open-source software you self-host), exposing a simple HTTP API for fetching package tarballs and metadata, plus auth for publishing.
3 use cases The default install source for every major JS package man... Show all
  • The default install source for every major JS package manager.
  • Publishing and distributing open-source JS/TS libraries.
  • Scoped + private packages for org-internal distribution.
4 features 3M+ packages — the largest software registry in the world. Show all
  • 3M+ packages — the largest software registry in the world.
  • Simple HTTP API for tarballs and version metadata.
  • Scoped packages (@org/pkg) and private publishing.
  • Mirrorable behind a proxy/cache (Verdaccio, Artifactory).

It’s a single hosted service, so it’s a supply-chain and availability choke point — typosquatting, dependency-confusion, and the occasional unpublished package (the infamous left-pad incident) all stem from trusting a public registry. Pin versions, use a lock file, and consider a caching proxy for CI.

 Hosted service npm, Inc. (GitHub / Microsoft) proprietary
Composer The dependency manager that modernized PHP.
★ standard🔧
🔧 Tooling
★ standard gentle 2012

The standard dependency manager for PHP — it reads a composer.json, resolves a compatible set of packages from the Packagist registry, writes a composer.lock for reproducible installs, and generates a PSR-4 autoloader so you never write require statements by hand. It’s the tool that made the modern PHP framework ecosystem (Laravel, Symfony) possible.
3 use cases Dependency management for any modern PHP project. Show all
  • Dependency management for any modern PHP project.
  • Installing and updating frameworks like Laravel or Symfony.
  • Autoloading classes via the generated PSR-4 autoloader.
4 features composer.json manifest + composer.lock for reproducible i... Show all
  • composer.json manifest + composer.lock for reproducible installs.
  • Pulls from the Packagist registry by default.
  • Generates a PSR-4 / classmap autoloader automatically.
  • Per-project dependencies (no global install soup).

Resolving large dependency graphs can be slow and memory-hungry — bumping PHP’s memory_limit for Composer is a common ritual. And always commit composer.lock: without it, composer install resolves fresh versions and you lose reproducibility across environments.

 PHP Composer team + OSS community MIT
Turborepo High-performance build orchestration for JS/TS monorepos.
▲ rising🔧
🔧 Tooling
▲ rising moderate 2021

A monorepo build system from Vercel that sits on top of your package manager’s workspaces and makes big repos fast through aggressive caching — it builds a task dependency graph, runs tasks in parallel, and skips any work whose inputs haven’t changed (locally and via a shared remote cache). It’s a task runner, not a package manager: pair it with npm, pnpm, or Yarn workspaces.
3 use cases Speeding up build/test/lint tasks across a JS/TS monorepo. Show all
  • Speeding up build/test/lint tasks across a JS/TS monorepo.
  • Sharing a remote build cache across a team and CI.
  • Orchestrating task pipelines with explicit dependencies.
4 features Content-aware caching — never rebuild unchanged tasks. Show all
  • Content-aware caching — never rebuild unchanged tasks.
  • Remote cache shared across machines and CI.
  • Parallel task execution from a dependency graph (turbo.json).
  • Layers on top of npm/pnpm/Yarn workspaces.

The cache only helps if your task inputs/outputs in turbo.json are declared accurately — get them wrong and you’ll either cache stale results or never get a cache hit. It’s an orchestrator on top of workspaces, not a replacement for your package manager.

 Rust Vercel + OSS community MIT