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

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.

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 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. 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. 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. 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. 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. js 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 ; When you need state and event handlers, app is the entry instead of page . Same primitives, same modifiers: js 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: page and app return single pages. Multi-page wiring is your code. app mounts on load. There is no SSR + hydration two-step. node .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: PairType / SelfClosingType / TextType . A tree walker emits HTML strings deterministically. <head <style ...</style </head . No global selector wars. .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. 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. 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: Card , Grid , Image variants, 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. If you give it a try, even a one-liner reaction in the comments or on social means a lot at this stage.