Getting Started

How to navigate and contribute comparisons.

This page walks through how the content in this project is organized.

Structure

Content lives under src/content/docs as plain Markdown files. Folders map directly to sections in the sidebar:

src/content/docs/
├── languages/
│   ├── programming/
│   └── markup/
├── frameworks/
│   ├── frontend/
│   │   ├── pure/
│   │   ├── meta/
│   │   ├── templating/
│   │   ├── server-driven-ui/
│   │   ├── ssg/
│   │   └── bundlers/
│   ├── mobile/
│   ├── desktop/
│   ├── backend/
│   ├── game-engines/
│   └── ai/
├── operating-systems/
│   ├── major-os/
│   └── linux-distros/
├── libraries/
│   ├── orm/
│   ├── validation/
│   ├── testing/
│   │   ├── unit/
│   │   └── e2e/
│   ├── cli/
│   └── logging/
└── misc/
    ├── databases/
    ├── servers/
    ├── git-hosting/
    ├── backend-as-a-service/
    └── cloud-platforms/

Almost every file follows the same shape: frontmatter, then one ## Item Name heading per language, framework, or tool, each followed by a short paragraph — a one-paragraph summary of how that item handles the topic, not an exhaustive deep dive. For example, languages/programming/concurrency.md has a ## Go section describing goroutines and channels, a ## Python section describing the GIL and asyncio, and so on for every language covered.

languages/ splits into programming/ (JavaScript, Python, Rust, Haskell, …) and markup/ (HTML, XML, Markdown, LaTeX, …), since markup languages don’t have variables, functions, or loops — they get their own topic set (syntax and structure, nesting, extensibility, parsers and tooling, use cases) instead of the programming-language one (typecheck, operators, concurrency, error handling, …).

frameworks/frontend/ is split into four narrower categories rather than one big list, since “frontend framework” covers pretty different things: pure/ covers UI libraries (React, Vue, Svelte, …), meta/ covers the frameworks built on top of them (Next.js, Nuxt, SvelteKit, …), templating/ covers server-side template engines (Pug, Blade, Jinja2, …) that aren’t JS frameworks at all, and server-driven-ui/ covers the Livewire-style pattern of pushing server-rendered HTML over the wire instead of shipping a client-side app (Hotwire, Phoenix LiveView, HTMX, Blazor Server, …).

frameworks/frontend/ssg/ compares static site generators — Astro, VuePress, VitePress, Gatsby, Docusaurus, Eleventy, Hugo, Jekyll, and Zola — on content authoring, build performance, and hydration model. Astro also appears in meta/, since it’s genuinely both a meta- framework and a static site generator; the two files cover it from different angles rather than duplicating each other. This category also doesn’t shy away from calling out which tools are declining or deprecated (Gatsby’s slowdown since its 2023 acquisition, VuePress being superseded by VitePress) instead of presenting every option as equally current.

frameworks/frontend/bundlers/ compares JS bundlers — Webpack, Rollup, Parcel, esbuild, Vite, Turbopack, Rspack, Bun, and Rolldown — on architecture, bundling strategy, dev-server/HMR behavior, speed, plugin compatibility, and adoption.

frameworks/game-engines/ compares Unity, Unreal Engine, Godot, GameMaker, Construct, CryEngine, Cocos Creator, Bevy, and Defold on scripting language, architecture (ECS vs. scene tree vs. actor model), rendering, platform support, and licensing/pricing — including non-obvious details like Unity’s cancelled 2023 runtime fee, Unreal’s 5% royalty past $1M revenue, and which engines (Godot, Bevy, Defold) are stewarded by a nonprofit foundation rather than a company.

frameworks/ai/ compares LLM application frameworks — Vercel AI SDK, TanStack AI, LangChain, LangGraph, LlamaIndex, Mastra, CrewAI, Semantic Kernel, and Haystack — on things like tool calling, orchestration, RAG/data integration, streaming, and observability, since this is now as distinct a “kind of framework” as frontend or backend.

operating-systems/ splits into major-os/, comparing Linux, Windows, macOS, iOS, Android, and ChromeOS on things like kernel architecture, file systems, security model, and licensing, and linux-distros/, which drills into how individual Linux distributions (Ubuntu, Debian, Fedora, Arch, …) differ from each other on release model, package management, init system, and default desktop — a distinction “Linux” as a single item in major-os/ can’t capture.

libraries/ sits alongside frameworks/ at the top level for tools that are libraries first, even when a framework happens to ship one built in. libraries/orm/ compares ORMs across languages and frameworks — Active Record (Rails), Eloquent (Laravel), Django ORM, Prisma, Drizzle, TypeORM, Sequelize, SQLAlchemy, Entity Framework Core, Hibernate (JPA), GORM, and Diesel — including how tightly each framework-bound ORM (Active Record, Eloquent, Django ORM) is fused to that framework’s own philosophy, versus the standalone ORMs usable with any framework in their language.

libraries/validation/ compares validation libraries across languages and frameworks — Zod, Valibot, ArkType, Joi (TypeScript/ JavaScript), Pydantic, Marshmallow (Python), Hibernate Validator (Java), FluentValidation (.NET), go-playground/validator (Go), Garde (Rust), Active Model Validations (Rails), and Laravel Validator — on schema definition style, static type inference, error handling, composability, custom/async rules, performance, and maturity. Like orm/, it calls out which entries are framework-built-in (Active Model Validations, Laravel Validator) versus standalone libraries usable with any framework in their language.

libraries/testing/ splits into unit/ and e2e/, since “testing library” covers two genuinely different jobs. unit/ compares Jest, Vitest, Mocha, pytest, JUnit, RSpec, Go’s built-in testing package, xUnit, PHPUnit, and Rust’s built-in tests across languages, on test syntax, assertions, mocking, and async support. e2e/ compares browser-automation tools — Playwright, Cypress, Selenium, Puppeteer, WebdriverIO, and TestCafe — on protocol/architecture, auto-waiting, parallelization, and debugging tooling, including current 2026 adoption data (Playwright’s roughly 45% vs. Cypress’s 14% market share) rather than treating them as equally popular.

libraries/cli/ compares CLI-building libraries across languages — Commander.js, Yargs, oclif (JS/TS), Click, argparse, Typer (Python), Cobra (Go), Clap (Rust), Thor (Ruby), picocli (Java), and Symfony Console (PHP) — on command/argument definition, help generation, subcommand nesting, plugin extensibility, interactive prompts, and startup performance, including concrete numbers where they matter (Commander’s ~500M weekly downloads vs. oclif’s ~2M, oclif’s ~200-500ms plugin-loading overhead vs. a single-digit-millisecond Clap binary).

libraries/logging/ compares logging libraries across languages — Winston, Pino (Node.js), Python’s built-in logging, Loguru (Python), Log4j2, Logback (Java), Zap, slog (Go), tracing (Rust), Serilog (.NET), and Monolog (PHP) — on structured logging, log levels, performance, transports/outputs, async/non-blocking writes, and context propagation (request IDs, spans). Performance claims are backed by real 2026 benchmark numbers rather than vague “X is faster” statements (Pino processing 100K calls in ~450ms vs. Winston’s ~2,800ms; Go’s slog at ~101ns/op vs. Zap’s near-zero-allocation hot path), and it notes where the ecosystem has consolidated around a single frontend, as with Go converging on slog since 1.21.

misc/backend-as-a-service/ compares BaaS platforms — Supabase, Firebase, Appwrite, Convex, PocketBase, Nhost, AWS Amplify, and Hasura — on the pieces they bundle together (database, auth, realtime, functions, storage) and how open or self-hostable each one is. Some items are honestly incomplete on some topics — Hasura, for instance, has no built-in storage or auth of its own — rather than papering over that with a made-up answer.

misc/cloud-platforms/ compares cloud/hosting providers — AWS, GCP, Azure, Vercel, Cloudflare, Netlify, DigitalOcean, Render, Fly.io, and Heroku — across most topics, but not every topic applies to every platform. serverless-and-edge-functions.md only covers the 7 platforms that actually ship a dedicated serverless/edge-function product and says so explicitly, rather than padding out sections for Render, Fly.io, and Heroku, which don’t have one.

The one exception to the “one file per topic” shape is misc/git-hosting/, where each platform (github/, gitlab/, bitbucket/) gets its own subfolder of single-subject pages, since there’s only one item per file rather than several being compared.

Reading a page

Click any file in the sidebar to open it. The page you’re reading right now is rendered straight from Markdown — no manual HTML involved.

Contributing

  1. Pick an existing topic file to extend, or add a new .md file under the relevant category folder for a new topic
  2. Include title (required) and description (optional) frontmatter
  3. Follow the ## Item Name + short paragraph pattern above — keep each paragraph a summary, not a tutorial
  4. New languages, frameworks, or tools should be added consistently across every topic file in that category, not just one