title: About kazam
shell: standard

components:
  - type: header
    title: About kazam
    eyebrow: What it replaces
    subtitle: A real migration from React to kazam, the use cases it fits, and the honest line on what it isn't.

  - type: section
    eyebrow: Receipts, not a pitch
    heading: What kazam replaces
    components:
      - type: markdown
        body: |
          A real personal site migrated from Create-React-App to kazam.
          Whole repo, not a hand-picked excerpt.

      - type: stat_grid
        columns: 3
        stats:
          - label: Hand-authored LOC
            value: "−88%"
            detail: 1,722 → 210
            color: green
          - label: npm dependencies
            value: "0"
            detail: was react, tailwind, axios, +1000s transitive
            color: green
          - label: Migration
            value: 1 conversation
            detail: one-shot rebuild with an agent
            color: default

      - type: before_after
        items:
          - title: Source you maintain
            before: 1,722 lines across React components, hooks, CSS modules, and Tailwind config.
            after: "**210 lines of YAML** — `kazam.yaml` + one file per page."
          - title: Dependency graph
            before: "react, react-router, axios, tailwind, react-gravatar, react-toggle + thousands of transitive npm packages you'll never audit."
            after: "**Zero npm dependencies.** ~10 direct Rust crates, `cargo-audit` in CI, `Cargo.lock` committed."
          - title: Build & deploy
            before: webpack build, Firebase Hosting, two cloud functions to patch over SPA quirks.
            after: "**One Rust binary** emits static HTML. Firebase Hosting serves `_site/` — no functions, no runtime."

  - type: section
    eyebrow: Use cases
    heading: What to build with it
    components:
      - type: card_grid
        cards:
          - title: Documentation sites
            badge:
              label: standard
              color: default
            description: API refs, guides, onboarding docs. Tabs for code samples, sortable tables for references.
            links:
              - label: See example →
                href: examples/doc.html

          - title: API references
            badge:
              label: standard
              color: default
            description: OpenAPI-style endpoint docs — request/response, parameters, code samples — without the Scalar/Stoplight/Redoc runtime. All from YAML.
            links:
              - label: See example →
                href: examples/api.html

          - title: Internal KBs & wikis
            badge:
              label: standard
              color: default
            description: Handbooks, runbooks, service catalogs. Card grids for navigation, tables for operational data.
            links:
              - label: See example →
                href: examples/kb.html

          - title: Meeting agendas & briefs
            badge:
              label: document
              color: default
            description: One-pagers and pre-reads. Centered card layout, print-optimized, exports clean to PDF.
            links:
              - label: See example →
                href: examples/agenda.html

          - title: Decks & presentations
            badge:
              label: deck
              color: default
            description: QBRs, strategy reviews, pitch decks. Full-viewport slides with keyboard nav and PDF export.
            links:
              - label: See example →
                href: examples/deck.html

          - title: Dashboards from APIs
            badge:
              label: pattern
              color: teal
            description: Scripts emit YAML, kazam renders. Live data from HN, GitHub, Linear, Sheets, or any JSON endpoint.
            links:
              - label: See walkthrough →
                href: examples/hackernews.html
              - label: Live HN top 30 →
                href: examples/hackernews-live.html

  - type: section
    eyebrow: Fit
    heading: Is this the right tool for what you're building?
    components:
      - type: markdown
        body: |
          kazam is narrow on purpose. It replaces the toolchain around **static content** —
          docs, references, internal pages, decks, briefs. It is **not** a replacement for a
          real web application framework. Here's the honest line.

      - type: markdown
        body: "### Use kazam for"

      - type: table
        columns:
          - key: use_case
            label: Use case
          - key: why
            label: Why it fits
        rows:
          - use_case: Documentation sites & API references
            why: Structured content, client-side table filter/sort, themed output. What kazam was built for.
          - use_case: Personal sites & portfolios
            why: Low interactivity, SEO-friendly static HTML. The tool's author replaced their CRA site this way.
          - use_case: Internal KBs, runbooks, handbooks
            why: YAML in git = reviewable in PRs. Card grids and tables cover most navigation patterns.
          - use_case: Pitch decks, QBRs, strategy reviews
            why: "`shell: deck` gives full-viewport slides with keyboard nav and clean PDF export."
          - use_case: Meeting agendas, briefs, one-pagers
            why: "`shell: document` centers a printable card. Exports cleanly to PDF."
          - use_case: Build-time dashboards
            why: Cron a script that emits YAML from your API, rebuild, deploy. Live-ish data, zero runtime.
          - use_case: Simple landing pages
            why: Hero, features, stats, CTA — all native components. Not its specialty, but it ships one fine.

      - type: markdown
        body: "### Reach for something else for"

      - type: table
        columns:
          - key: use_case
            label: Use case
          - key: instead
            label: Reach for instead
        rows:
          - use_case: Apps with logged-in state or user accounts
            instead: Next.js, Remix, Rails, Django — kazam has no auth, no sessions, no server.
          - use_case: E-commerce checkout & payments
            instead: Shopify, or a real app framework with a backend.
          - use_case: Real-time feeds, chat, collaborative editing
            instead: Anything with a websocket. Static output can't push.
          - use_case: CMSes for non-technical authors
            instead: Notion, Sanity, Contentful. Authoring kazam content means editing YAML in git.
          - use_case: Per-request personalized pages
            instead: Next.js / Remix SSR. kazam builds once, serves the same bytes to everyone.
          - use_case: Rich client-side SPAs & admin dashboards
            instead: React / Vue / Svelte. kazam emits zero JS by design.
          - use_case: Blogs with comments or user-generated content
            instead: Ghost, WordPress, or any app with a real backend. A read-only blog is fine.

  - type: callout
    variant: info
    title: Next up
    body: If this is a fit for what you're building, the next question is how it actually works — three shells, typed components, zero JS on the output.
    links:
      - label: How it works
        href: how.html
        variant: primary
      - label: Install it
        href: guide.html
        variant: secondary
