I don't want to write HTML or fight global CSS, so I built a TypeScript DSL

TL;DR

I got tired of writing HTML and chasing global CSS rules. I had a hunch: what if you could write a page the same way you write an app — same declarative tree, same modifier chains, scoped style per node? I spent a year quietly testing the bet on my own side projects.

It... seems okay? I've open-sourced it as DraftOle (npm / live demo).

• page() writes plain static HTML + scoped CSS — zero runtime JavaScript shipped.
• app() adds reactive state() and event handlers — TypeScript arrow functions get serialized into a minimal runtime at build time.
• Same DSL, same modifiers, in both cases.
• No bundler, no JSX, no template language, zero production dependencies.

  pnpm add draft-ole
  # or npm install draft-ole
  # or yarn add draft-ole

This is the 0.9.0 pre-1.0 release. The API surface is essentially settled and 1.0 is the next tag, but I'm intentionally holding back the 1.0 promise until I hear from real users. If you try it and it feels great or terrible, please tell me — both signals are useful.

(Yes, AI can generate HTML/CSS now. I'm not making a claim about how DraftOle compares — that's a separate experiment I haven't run. This article is just about what I built and why.)

## Honestly? I just don't want to write HTML or global CSS anymore

Let me be candid about the motivation. It's not a refined "type safety extends to the leaves" pitch. It's two embarrassingly small frustrations I kept hitting on every side project.

1. I don't want to write HTML

I'm building logic in TypeScript — typed values, typed functions, typed data flow — and then at the last mile I have to drop into stringly-typed HTML. Attribute names are strings. Class names are strings. Five levels of nesting and I can't tell which element carries which style anymore. The logical layer is type-safe, and then the presentation layer reverts to "paste these strings together carefully." That mismatch grates every time.

2. I don't understand global CSS

CSS-in-JS, CSS Modules, Tailwind — pick your weapon, eventually you write a rule against body or *, and now your scoping assumptions are gone. For a one-page LP I'd spend more time chasing "where is this style coming from" in DevTools than writing the page itself. After enough projects you just sigh and accept it.

3. Apps are declarative — why aren't pages?

When I build apps in React or SwiftUI, none of this bothers me. You drop a Text inside a VStack, you call .padding(), the style attaches to that node. Structure and style coexist in a tree and stay local to it.

What if I could write a page the same way? Would the HTML problem and the CSS problem both just dissolve?

That was the bet. I wrote a private View DSL for a year, dogfooded it on my own landing pages and small apps, and eventually thought "you know, this might actually be okay to release." So I cleaned it up and pushed draft-ole@0.9.0.

A pleasant side effect of basing the whole thing on a typed view tree: HTML attribute typos become compile errors. The TypeScript checker reaches all the way to your <div>. That wasn't the primary goal — it's just what falls out when you build a strongly-typed view model.

What DraftOle looks like in practice

A static page

  import { page, Section, VStack, Text, Heading } from 'draft-ole';

  const hero = Section(
    VStack({ spacing: 16 },
      Heading(1, 'Hello, DraftOle!')
        .font({ size: '2.75rem', weight: '800' })
        .foregroundStyle('#0f172a'),
      Text('A TypeScript-native View DSL.')
        .font({ size: '1.125rem' })
        .foregroundStyle('#475569'),
    )
      .padding(48)
      .frame({ maxWidth: 720 }),
  )
    .background('#f8f9ff');

  const doc = page(hero, { lang: 'en', title: 'Hello' });

  doc.export('./dist');   // writes index.html + style.css

Run with node --experimental-strip-types build.ts (or tsx, or ts-node). The output is plain HTML and scoped CSS. Zero runtime JavaScript ships to the browser.

The modifier-chain shape is borrowed from SwiftUI's ViewModifier:

  // SwiftUI
  VStack(spacing: 16) {
      Text("Hello")
          .font(.title)
          .foregroundStyle(.primary)
  }
  .padding(48)

  // DraftOle
  VStack({ spacing: 16 },
    Text('Hello')
      .font({ size: '2rem', weight: '800' })
      .foregroundStyle('#0f172a'),
  ).padding(48);

An interactive app

When you need state and event handlers, app() is the entry instead of page(). Same primitives, same modifiers:

  import { app, el, vstack, hstack } from 'draft-ole';

  const doc = app({ title: 'Counter', lang: 'en' });
  const count = doc.state(0);

  const display = el.span()
    .text(count.map((n) => String(n)))
    .font({ size: '4rem', weight: '700', family: 'monospace' });

  const incBtn = el.button({ type: 'button' }, '+1')
    .on('click', () => count.set(count.get() + 1))
    .padding('10px 24px')
    .background('#6d28d9')
    .foregroundStyle('#ffffff')
    .cornerRadius('8px');

  const view = vstack({ spacing: 20 }, display, incBtn).padding(48);

  doc.exportTo('./dist', view);   // writes index.html + style.css + script.js

doc.state<number>(0) returns a reactive value. .on('click', () => count.set(count.get() + 1)) accepts a TypeScript arrow function. At build time, the function body is extracted from the AST, serialized into runtime JavaScript, and embedded into script.js. The state subscription engine is a few hundred lines and ships with the output — that's the only runtime DraftOle adds when you use app().

The arrow function can only capture variables that go through the state API (.get / .set / .map / .update / .field / .each). Capturing anything else (a closed-over variable, an outer-scope helper) is a compile-time error — the serializer needs a closed surface to work with.

examples/interactive/ ships with working demos of Counter, Todo, Form, Shopping Cart, Card Gallery, and Priority Tasks. The Todo app is around 100 lines.

## What DraftOle does not do

I'll leave you to draw comparisons against whatever you're currently using. What I can describe is the scope I have not implemented:

• No router / multi-page convention. page() and app() return single pages. Multi-page wiring is your code.
• No SSR / hydration. app() mounts on load. There is no SSR + hydration two-step.
• No pre-built component ecosystem. You get view primitives and modifiers. Higher-level components are yours to build.
• No file-based pages. A page is a TypeScript file you run with node.
• No state persistence (localStorage / URL sync). Handle it in your application code.

If any of these are required for your use case, DraftOle is not the right tool today, and that is fine.

## How the internals work (a little)

For the curious:

• View → HTML mapping: each primitive returns a PairType / SelfClosingType / TextType. A tree walker emits HTML strings deterministically.
• Scoped CSS: every styled view gets a hash-suffixed class name. CSS is inlined into <head><style>...</style></head>. No global selector wars.
• TypeScript transformer: a custom TS transformer plugin extracts arrow-function bodies from .on(event, fn) calls at the AST level and serializes them into runtime JavaScript. Anything that captures non-state-API closures is a compile-time error.
• Zero deps: package.json#dependencies is empty. Everything in node_modules/draft-ole/ is DraftOle's own code.

If reading source code as a documentation form appeals to you, src/transformer/ has handler-serializer.ts, each-state-rewriter.ts, and inline-recovery.ts — they're some of the more interesting parts.

## Try it in 60 seconds

  mkdir try-draftole && cd try-draftole
  pnpm init -y
  pnpm add draft-ole

  cat > hello.ts <<'EOF'
  import { page, Section, Text } from 'draft-ole';
  const doc = page(
    Section(Text('Hello from DraftOle.').padding(48)).background('#f0f4ff'),
    { lang: 'en', title: 'Hi' },
  );
  doc.export('./out');
  EOF

  node --experimental-strip-types hello.ts
  open out/index.html

That's it. One TypeScript file, one node command, plain static HTML on disk.

What's next

0.9.0 is a feedback window. The API surface is essentially settled and 1.0 is the next tag, but I'm intentionally holding back the 1.0 promise until I hear from real users. Things I most want feedback on:

1. Does the SwiftUI-style modifier API feel natural in TypeScript, or weird?
2. Are there view primitives you reached for and couldn't find? (Common candidates: Card, Grid, Image variants, form controls.)
3. Does anything in the README sound like marketing rather than honest description?

GitHub Issues and Discussions are both open. "I tried it and it doesn't fit my use case" is a valuable signal too — I want to know where the seams are.

Links

• GitHub: https://github.com/object-zaseeta/DraftOle
• npm: https://www.npmjs.com/package/draft-ole
• Live demo: https://draftole-demo.netlify.app/ (this LP is built with DraftOle itself — source)
• Positioning doc: docs/positioning.md

If you give it a try, even a one-liner reaction in the comments or on social means a lot at this stage.

Comments

[Harjot Singh]

Building a TypeScript DSL to escape global-CSS hell is a classic "encode the constraint in the type system" move, and it's the right instinct - the whole pain of global CSS is that nothing stops you from colliding, so pushing the structure into TS means the compiler enforces what discipline used to. The tradeoff people will poke at is the usual DSL one: you trade the entire CSS ecosystem (every example, every Stack Overflow answer, every existing stylesheet) for type-safety and locality, so the bet pays off when the safety/composability you gain outweighs the "now it's a thing only my project understands" cost. For a personal/internal scope that's often a great trade.

The reason this resonates with me: I think the highest-leverage engineering is exactly this - encoding the opinion so the wrong thing becomes hard to express. That's the core idea behind Moonshift, a multi-agent pipeline that takes a prompt to a deployed SaaS on your own GitHub + Vercel, where the architecture and the boring-but-critical parts are encoded as verified defaults instead of left to drift. Same spirit as a DSL that makes bad CSS unrepresentable. Multi-model routing keeps a build ~$3 flat, first run's free no card. Nice work. Are you generating real stylesheets at build time from the DSL, or runtime style injection? The build-time path is where the type-safety really pays off without the runtime cost.