Loom

The speed of no-code. The keys to the codebase.

Loom is a high-level DSL that lets you describe complete systems at the altitude of a no-code platform — and walk away with real, owned source code across five backends (Hono, .NET, Phoenix LiveView, Java/Spring Boot, Python/FastAPI) and six frontends (React, Vue, Svelte, Angular, Feliz (F#/Fable), Flutter). No vendor lock-in. No scaling cliff. Every layer is generated from one model, so the layers share one contract (a target can still lag on a feature — the known gaps are listed; see What's in the box). Just the model, a visual builder, and full ownership of every line that's generated.

• All the speed of no-code
• All the source you'd write by hand
• Zero vendor lock-in

Live site: https://loom-harness.github.io/Loc/ — landing, browser playground (typed editor + visual system builder + live preview + in-browser test runner), and the full documentation set.

---

At a glance

Backends	Hono · .NET · Phoenix LiveView · Java/Spring Boot · Python/FastAPI
Frontends	React · Vue · Svelte · Angular · Feliz (F#/Fable) · Flutter
Design systems	Mantine · shadcn/ui · MUI · Chakra (React) · Vuetify · shadcnVue (Vue) · shadcnSvelte · Flowbite (Svelte) · Angular Material · PrimeNG · Spartan/NG (Angular) · Phoenix HEEx (coreComponents, daisyui) — swap any time
Visual tools	Typed editor · system builder · live preview · in-browser test runner
Quality story	requirement → solution → testCase → test → ddd verify → per-requirement Definition-of-Done verdicts
LLM-safe	One source of truth · validated before emission · refactor the model, regenerate the stack

Versus the alternatives

Every shortcut to building a system has a hidden tax — lock-in, drift, framework jail, or a scaling cliff. Loom is the row where everything turns into a check mark:

• vs no-code/low-code (Bubble, Retool, OutSystems, Mendix, Appsmith): same minutes-to-first-prototype, but you own the source, there's no scaling cliff, no platform lock-in.
• vs starter kits / frameworks (Rails, Phoenix, Blitz, Wasp): same source ownership, but Loom is a single source of truth across all layers (frontend, backend, DB, tests) instead of one framework's conventions.
• vs AI codegen (Cursor projects, v0, Bolt, Lovable): same speed at the prompt, but no architectural drift after a few prompts — the model is the source of truth, the LLM can't hallucinate fields the model doesn't have or write a frontend that disagrees with its backend.

Full feature-by-feature comparison: https://loom-harness.github.io/Loc/#compare.

Quick example

A complete .ddd source — domain, deployables across three runtimes, an end-to-end test:

system Acme {
  subdomain Sales {
    context Orders {

      enum OrderStatus { Draft, Confirmed, Shipped, Cancelled }

      valueobject Money {
        amount: decimal
        currency: string
        invariant amount >= 0
        invariant currency.length == 3
      }

      event OrderConfirmed { order: Order id, at: datetime }

      aggregate Order with crudish {
        customerId: string
        status: OrderStatus
        placedAt: datetime
        contains lines: OrderLine[]

        derived total: Money =
          Money { amount: lines.sum(l => l.subtotal.amount), currency: "USD" }

        invariant lines.count > 0 when status == Confirmed

        function isMutable(): bool = status == Draft

        operation confirm() {
          precondition isMutable()
          precondition lines.count > 0
          status := Confirmed
          emit OrderConfirmed { order: id, at: now() }
        }

        operation addLine(productId: Product id, qty: int, price: Money) {
          precondition isMutable()
          lines += OrderLine { productId: productId, quantity: qty, unitPrice: price }
        }

        entity OrderLine {
          productId: Product id
          quantity: int
          unitPrice: Money
          derived subtotal: Money =
            Money { amount: unitPrice.amount * quantity, currency: unitPrice.currency }
          invariant quantity > 0
        }
      }

      repository Orders for Order { }
    }
  }

  subdomain Catalog {
    context Products {
      aggregate Product with crudish {
        sku: string
        price: Money
        derived display: string = sku
      }
      repository Products for Product { }
    }
  }

  storage primary { type: postgres }
  resource orderState   { for: Orders,   kind: state, use: primary }
  resource productState { for: Products, kind: state, use: primary }

  // Pick a runtime per deployable.  Switch any time.
  deployable api    { platform: node,   contexts: [Orders, Products], dataSources: [orderState, productState], port: 3000 }
  deployable apiNet { platform: dotnet, contexts: [Orders, Products], dataSources: [orderState, productState], port: 8080 }
  deployable apiPhx { platform: elixir, contexts: [Orders, Products], dataSources: [orderState, productState], port: 4000 }

  ui WebApp with scaffold(subdomains: [Sales, Catalog]) { }

  // React frontend targets any backend; design pack swappable.
  deployable webApp {
    platform: react
    targets:  api          // switch to apiNet or apiPhx anytime
    ui:       WebApp
    design:   shadcn       // or mantine, mui, chakra
    port:     3001
  }

  test e2e "create and confirm an order" against api {
    let prod = api.products.create({ sku: "W-1", price: { amount: 5.0, currency: "USD" } })
    let ord  = api.orders.create({ customerId: "c-1", status: "Draft", placedAt: "2024-01-01T00:00:00Z" })
    api.orders.addLine(ord, { productId: prod.id, qty: 3, price: { amount: 5.0, currency: "USD" } })
    api.orders.confirm(ord)
    let read = api.orders.getById(ord)
    expect(read.status).toBe("Confirmed")
    expect(read.lines.length).toBe(1)
  }
}

node bin/cli.js generate system acme.ddd -o ./out → runnable multi-project tree + docker-compose.yml + healthchecks + generated migrations + e2e suite. docker compose up -d → everything running on ports 3000 / 8080 / 4000 / 3001.

Every REST route the backends serve is mounted under /api, named by the aggregate's snake_cased plural — so it is curl localhost:3000/api/orders (and /api/orders/{id}), not /orders. The full surface of a generated backend is always its own GET /openapi.json.

Install

npm install
npm run langium:generate    # generate the parser from src/language/ddd.langium
npm run build               # tsc -b

Requires Node 20+.

There is no global ddd on your PATH after this — npm install in a clone does not link the bin. Every command below is spelled node bin/cli.js <args> from the repo root; npx ddd <args> works too, but only inside the clone — anywhere else it fetches an unrelated npm package named ddd (Loom is not published to npm). Add alias ddd='node "$PWD/bin/cli.js"' if you want the short form in a shell session.

CLI

node bin/cli.js parse <file.ddd>                       # parse + validate, exit non-zero on errors
node bin/cli.js generate ts     <file.ddd> -o <out>    # single Hono project (legacy single-context mode)
node bin/cli.js generate dotnet <file.ddd> -o <out>    # single .NET project (legacy)
node bin/cli.js generate system <file.ddd> -o <out>    # full multi-deployable tree + docker-compose.yml
node bin/cli.js snapshot        <file.ddd> -o <out>    # capture immutable .loom/snapshots/<ts>-<guid>.loomsnap.json (provenance rule snapshot)
node bin/cli.js verify          <file.ddd> --results <results.json>  # join existing test-results onto the requirements graph → .loom/verification.{json,md} (gates the exit code; does NOT run the suites)
node bin/cli.js verify  <file.ddd> --from-vitest <report.json>  # …reading `vitest run --reporter=json` directly

Common flags:

Flag	Effect
-o, --out <dir>	Output directory. Created if missing.
-w, --watch	Re-run the generator on every save of the .ddd source (legacy generate ts / generate dotnet only).
--dry-run	Print the plan with write / skip annotations; touch nothing.

ddd parse exits non-zero on validation errors. All generate sub-commands run validation first and refuse to emit if there are errors.

What's in the box

Five backends from one source. Hono (TypeScript), ASP.NET Core (.NET), Phoenix LiveView (Elixir, plain Ecto/Phoenix), Spring Boot (Java), and FastAPI (Python). Six frontends — React, Vue, Svelte, Angular, Feliz (F#/Fable/Elmish), Flutter. Pick per deployable. Switch any time. One wire contract, derived from one model, and checked on every PR by the cross-backend wire differential (docs/conformance.md); idiomatic per-runtime output. Not every feature reaches every backend yet: the known per-backend gaps are listed in the unsupported register (each row a loom.*-unsupported diagnostic the compiler raises) and in docs/conformance.md § What the harness can't catch.

Thirteen design packs. Mantine, shadcn/ui, MUI, Chakra (React), Vuetify, shadcnVue (Vue), Flowbite, shadcnSvelte (Svelte), Angular Material, PrimeNG, Spartan/NG (Angular), and the Phoenix HEEx packs (coreComponents, daisyui) ship in-tree. The page DSL is identical; only the rendering changes. Bring your own — design packs are just templates against a small page contract.

Browser playground. Typed editor with LSP support, visual system builder for deployables and modules, live preview of the generated app booting in a sandboxed iframe, in-browser test runner. Same .ddd source across all views. Open it at https://loom-harness.github.io/Loc/playground/.

Built-in traceability. Declare requirement, solution, and testCase alongside your domain. Executable tests link back to test cases; ddd verify rolls results into per-requirement Definition-of-Done verdicts in .loom/verification.{md,json}. No separate Jira/CI/git triangulation.

LLM-safe by construction. One source of truth across frontend, backend, database, and tests — they regenerate together. The DSL is small enough to fit in a prompt. Validation gates catch hallucinated fields and out-of-scope references before any code is emitted.

Per-aggregate generation. Aggregate roots with private state, factories, invariant checks, derived properties, domain events. Repositories with find-by-id, save, find-all, plus your finds, all with master-detail load/save. HTTP routes per operation and find. Generated migrations (Drizzle / EF Core / Ecto / JPA / SQLAlchemy). Generated UI pages (list, detail, create) with a modal-form button per public operation. Generated end-to-end tests against the live stack — the same DSL test runs against whichever runtime you point it at.

Examples

Example	Highlights
sales.ddd	DDD basics — Order aggregate with OrderLine parts, Money value object, OrderStatus enum, OrderConfirmed event, repository with byCustomer find, test blocks.
banking.ddd	Optional fields, multiple aggregates with cross-references via X id, richer where-filter on a repository find.
inventory.ddd	Nested parts, explicit ids guid override on an aggregate.
money-primitive.ddd	The Money primitive and how decimal arithmetic is preserved across backends.
provenance.ddd	provenanced fields + the runtime trace SDK for explaining business decisions.
roster.ddd	X id[] association collections and the join tables generated for them.
sales-ui.ddd	Historical prototype — does not parse. The page-metamodel discussion's target syntax; several names in it were never shipped or were retired. Kept as the design record (its own header says so); read for the shipping page DSL.

Project layout

src/
  language/        # Langium grammar, scoping, themed validators, type system, LSP, .ddd printer
  macros/          # macro pipeline — expander, registry, authoring API, stdlib (scaffold/audit/softDelete/crudish)
  ir/              # IR types, lowering, enrichment, validation
  generator/
    typescript/    # shared TypeScript emitter (consumed by the Hono backend)
    dotnet/        # ASP.NET Core + EF Core + Mediator backend
    java/          # Spring Boot + Spring Data JPA backend
    python/        # FastAPI + SQLAlchemy backend
    elixir/        # Phoenix LiveView backend (plain Ecto/Phoenix, HEEx walker)
    react/ vue/ svelte/ angular/ feliz/ flutter/   # the six frontends + walker targets + page-object generators
    _packs/        # design-pack discovery + loader (13 pack families)
    _walker/       # cross-framework walker registry + WalkerTarget contract
    _expr/ _type/ _workflow/   # shared dispatchers + per-backend leaf tables
    _obs/          # observability catalog + per-backend log renderers
  platform/        # PlatformSurface registry + version pinning; Hono: shared emitter in platform/hono/v4, registered node@v5 in platform/hono/v5
  system/          # multi-deployable orchestrator + docker-compose + .loom/ artifact bundle
  verify/          # ddd verify rollup (joins test results onto traceability)
  mcp/ dap-server/ # MCP + DAP stdio-server cores (Node-only islands over src/tools + src/dap)
  cli/             # bin entry point
  util/            # naming + code-building helpers

packages/          # published workspaces: @loom/core · @loom/backend-hono-v5 · @loom/ui-test-driver · ddd-mcp · ddd-dap
web/               # browser playground (editor, system builder, live preview, test runner)
vscode/            # VS Code extension (LSP client)
designs/           # 13 design-pack families (versioned) — mantine, mui, chakra, shadcn (React); vuetify, shadcnVue (Vue); flowbite, shadcnSvelte (Svelte); angularMaterial, primeng, spartanNg (Angular); coreComponents, daisyui (HEEx)
stacks/            # versioned generated-project dependency manifests (v1, v3, vue1, sv1, ng1)
test/              # vitest suites + opt-in docker e2e
examples/          # sample .ddd sources
docs/              # full reference documentation

VS Code extension

The sibling vscode/ package ships a minimal VS Code extension that bundles the Loom language server. Install locally from a built .vsix:

cd vscode
npm install
npm run build
npm run package      # produces loom-ddd-0.1.0.vsix
code --install-extension loom-ddd-0.1.0.vsix

What you get: syntax highlighting, hover with inferred types, go-to-definition (including member access), type-driven completion, workspace symbols (Cmd+T), a "Loom: Generate from current file" command, and an "Unfold macro" code action that rewrites a with X(...) clause into its expanded source in place. See vscode/README.md for details.

Documentation

docs/README.md is the canonical doc index. The headline references:

Doc	Contents
language.md	Formal language reference — declarations, types, expressions, statements, validation rules, e2e test syntax.
page-metamodel.md	The ui / page / component / scaffold surface and the closed walker-stdlib primitive set.
architecture.md	System-level composition — module, deployable, api, storage, ui and how they wire together.
generators.md	Per-platform feature matrix — what each backend emits, file-by-file.
design-packs.md	Design-pack authoring guide; how to add your own pack version.
platforms.md	Backend registry, family@version pinning, the PlatformSurface contract.
tools.md	CLI usage, .loomignore, watch mode, Docker workflow, OpenAPI parity check, proxy CAs.

Per-feature references — auth.md, tenancy.md, workflow.md, payloads.md, inheritance.md, channels.md, extern.md, capabilities.md, scaffold-macros.md, provenance.md, observability.md, traceability.md, conformance.md, migrations.md, verify.md, — plus for the macro authoring surface, for the derived-artifact directory, and for usage terms.

Work state — the roadmap, open gaps, who is on what — lives in GitHub issues. The legacy design record (plans, proposals, audits, the mission plan) is no longer in the tree; browse it in history.

Plus experience_gathered.md — running retrospective of design choices and gotchas; worth reading before non-trivial changes.

Status

• 1,300+ test files / 9,000+ tests cover parsing, validation, all five backends and six frontends, the system orchestrator, the CLI, design-pack rendering, and the cross-platform OpenAPI parity harness.
• Opt-in suites gated on LOOM_E2E=1 / LOOM_TS_BUILD=1 / LOOM_REACT_BUILD=1 / LOOM_DOTNET_BUILD=1 / LOOM_JAVA_BUILD=1 / LOOM_PYTHON_BUILD=1 / LOOM_PHOENIX_VANILLA_BUILD=1 / LOOM_OBS_E2E*=1 build and boot the generated stacks against real toolchains (vitest, tsup, tsc, dotnet build /warnaserror, gradle testClasses bootJar, uv sync + ruff + mypy + pytest, mix compile --warnings-as-errors).
• CI matrix generates every example against every design pack and tsc --noEmits the frontend output; the backends are compiled against real toolchains — .NET dotnet build /warnaserror'd, Java built with Gradle, Python type-checked with mypy, and Phoenix compiled against plain Ecto/Phoenix in an Elixir docker image.

License

The generator in this repository is licensed under FSL-1.1-Apache-2.0 — Functional Source License 1.1 with an Apache 2.0 future license. Source-available for any non-competing use today; converts to a true open-source license (Apache 2.0) two years after publication.

The code Loom generates is licensed to you under the MIT License, with no FSL terms attaching to it. That grant covers everything the generator writes — every file ddd generate (including ddd generate system) emits into <outdir>/, and every file ddd new scaffolds — and it holds regardless of which verb produced the file. Production users can ship generated projects without inheriting any FSL terms.

The grant lives in the generator's own licence terms (this LICENSE plus §2 of the licence FAQ), not in a file written into your output directory. ddd new does scaffold a LICENSE file carrying the MIT grant into the starter project it creates; ddd generate deliberately writes none — it emits build output into a tree whose identity files are yours, and a LICENSE it re-created on every regenerate would overwrite your own. Nothing about the grant depends on that file: generated output is MIT whether or not a LICENSE sits beside it.

For the full posture — what counts as Competing Use, how runtime helpers are licensed when they ship inside generated projects, and what to tell legal/procurement — see docs/license-faq.md.