{"slug": "i-don-t-want-to-write-html-or-fight-global-css-so-i-built-a-typescript-dsl", "title": "I don't want to write HTML or fight global CSS, so I built a TypeScript DSL", "summary": "A developer who grew tired of writing HTML and managing global CSS has open-sourced DraftOle, a TypeScript-native View DSL that compiles to plain static HTML and scoped CSS with zero runtime JavaScript. The tool, currently at version 0.9.0, allows developers to build pages using the same declarative tree and modifier chains used in app frameworks like SwiftUI, with TypeScript catching attribute typos at compile time. The creator is holding back the 1.0 release to gather feedback from real users.", "body_md": "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.\n\nIt... seems okay? I've open-sourced it as ** DraftOle** (\n\n`page()`\n\nwrites plain static HTML + scoped CSS — zero runtime JavaScript shipped.`app()`\n\nadds reactive `state()`\n\nand event handlers — TypeScript arrow functions get serialized into a minimal runtime at build time.\n\n```\n  pnpm add draft-ole\n  # or npm install draft-ole\n  # or yarn add draft-ole\n```\n\nThis 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.\n\n(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.)\n\n## Honestly? I just don't want to write HTML or global CSS anymore\n\nLet 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.\n\nI'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.\n\nCSS-in-JS, CSS Modules, Tailwind — pick your weapon, eventually you write a rule against `body`\n\nor `*`\n\n, 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.\n\nWhen I build apps in React or SwiftUI, none of this bothers me. You drop a `Text`\n\ninside a `VStack`\n\n, you call `.padding()`\n\n, the style attaches to that node. Structure and style coexist in a tree and stay local to it.\n\n**What if I could write a page the same way? Would the HTML problem and the CSS problem both just dissolve?**\n\nThat 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`\n\n.\n\nA 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>`\n\n. That wasn't the primary goal — it's just what falls out when you build a strongly-typed view model.\n\n``` js\n  import { page, Section, VStack, Text, Heading } from 'draft-ole';\n\n  const hero = Section(\n    VStack({ spacing: 16 },\n      Heading(1, 'Hello, DraftOle!')\n        .font({ size: '2.75rem', weight: '800' })\n        .foregroundStyle('#0f172a'),\n      Text('A TypeScript-native View DSL.')\n        .font({ size: '1.125rem' })\n        .foregroundStyle('#475569'),\n    )\n      .padding(48)\n      .frame({ maxWidth: 720 }),\n  )\n    .background('#f8f9ff');\n\n  const doc = page(hero, { lang: 'en', title: 'Hello' });\n\n  doc.export('./dist');   // writes index.html + style.css\n```\n\nRun with `node --experimental-strip-types build.ts`\n\n(or `tsx`\n\n, or `ts-node`\n\n). The output is plain HTML and scoped CSS. Zero runtime JavaScript ships to the browser.\n\nThe modifier-chain shape is borrowed from SwiftUI's ViewModifier:\n\n```\n  // SwiftUI\n  VStack(spacing: 16) {\n      Text(\"Hello\")\n          .font(.title)\n          .foregroundStyle(.primary)\n  }\n  .padding(48)\n// DraftOle\n  VStack({ spacing: 16 },\n    Text('Hello')\n      .font({ size: '2rem', weight: '800' })\n      .foregroundStyle('#0f172a'),\n  ).padding(48);\n```\n\nWhen you need state and event handlers, `app()`\n\nis the entry instead of `page()`\n\n. Same primitives, same modifiers:\n\n``` js\n  import { app, el, vstack, hstack } from 'draft-ole';\n\n  const doc = app({ title: 'Counter', lang: 'en' });\n  const count = doc.state(0);\n\n  const display = el.span()\n    .text(count.map((n) => String(n)))\n    .font({ size: '4rem', weight: '700', family: 'monospace' });\n\n  const incBtn = el.button({ type: 'button' }, '+1')\n    .on('click', () => count.set(count.get() + 1))\n    .padding('10px 24px')\n    .background('#6d28d9')\n    .foregroundStyle('#ffffff')\n    .cornerRadius('8px');\n\n  const view = vstack({ spacing: 20 }, display, incBtn).padding(48);\n\n  doc.exportTo('./dist', view);   // writes index.html + style.css + script.js\n```\n\n`doc.state<number>(0)`\n\nreturns a reactive value. `.on('click', () => count.set(count.get() + 1))`\n\naccepts a **TypeScript arrow function**. At build time, the function body is extracted from the AST, serialized into runtime JavaScript, and embedded into `script.js`\n\n. 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()`\n\n.\n\nThe arrow function can only capture variables that go through the state API (`.get / .set / .map / .update / .field / .each`\n\n). 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.\n\n`examples/interactive/`\n\nships with working demos of Counter, Todo, Form, Shopping Cart, Card Gallery, and Priority Tasks. The Todo app is around 100 lines.\n\n## What DraftOle does not do\n\nI'll leave you to draw comparisons against whatever you're currently using. What I can describe is the scope I have not implemented:\n\n`page()`\n\nand `app()`\n\nreturn single pages. Multi-page wiring is your code.`app()`\n\nmounts on load. There is no SSR + hydration two-step.`node`\n\n.If any of these are required for your use case, DraftOle is not the right tool today, and that is fine.\n\n## How the internals work (a little)\n\nFor the curious:\n\n`PairType`\n\n/ `SelfClosingType`\n\n/ `TextType`\n\n. A tree walker emits HTML strings deterministically.`<head><style>...</style></head>`\n\n. No global selector wars.`.on(event, fn)`\n\ncalls at the AST level and serializes them into runtime JavaScript. Anything that captures non-state-API closures is a compile-time error.`package.json#dependencies`\n\nis empty. Everything in `node_modules/draft-ole/`\n\nis DraftOle's own code.If reading source code as a documentation form appeals to you, `src/transformer/`\n\nhas `handler-serializer.ts`\n\n, `each-state-rewriter.ts`\n\n, and `inline-recovery.ts`\n\n— they're some of the more interesting parts.\n\n## Try it in 60 seconds\n\n```\n  mkdir try-draftole && cd try-draftole\n  pnpm init -y\n  pnpm add draft-ole\n\n  cat > hello.ts <<'EOF'\n  import { page, Section, Text } from 'draft-ole';\n  const doc = page(\n    Section(Text('Hello from DraftOle.').padding(48)).background('#f0f4ff'),\n    { lang: 'en', title: 'Hi' },\n  );\n  doc.export('./out');\n  EOF\n\n  node --experimental-strip-types hello.ts\n  open out/index.html\n```\n\nThat's it. One TypeScript file, one node command, plain static HTML on disk.\n\n0.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:\n\n`Card`\n\n, `Grid`\n\n, `Image`\n\nvariants, form controls.)[GitHub Issues](https://github.com/object-zaseeta/DraftOle/issues) and [Discussions](https://github.com/object-zaseeta/DraftOle/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.\n\nIf you give it a try, even a one-liner reaction in the comments or on social means a lot at this stage.", "url": "https://wpnews.pro/news/i-don-t-want-to-write-html-or-fight-global-css-so-i-built-a-typescript-dsl", "canonical_source": "https://dev.to/kazuy/i-dont-want-to-write-html-or-fight-global-css-so-i-built-a-typescript-dsl-406d", "published_at": "2026-05-31 00:40:20+00:00", "updated_at": "2026-05-31 01:12:47.407567+00:00", "lang": "en", "topics": ["ai-tools", "ai-products", "ai-startups"], "entities": ["DraftOle", "TypeScript"], "alternates": {"html": "https://wpnews.pro/news/i-don-t-want-to-write-html-or-fight-global-css-so-i-built-a-typescript-dsl", "markdown": "https://wpnews.pro/news/i-don-t-want-to-write-html-or-fight-global-css-so-i-built-a-typescript-dsl.md", "text": "https://wpnews.pro/news/i-don-t-want-to-write-html-or-fight-global-css-so-i-built-a-typescript-dsl.txt", "jsonld": "https://wpnews.pro/news/i-don-t-want-to-write-html-or-fight-global-css-so-i-built-a-typescript-dsl.jsonld"}}