Build anything our website clients ask for — quickly, visually, with a very high ceiling on functionality.
The modern WordPress block builder gave us a head start, but the legacy liabilities are crushing:
It's 2026. Let's just build modern websites and apps with modern web APIs — using a visual builder.
Five eras. Each solved one problem and inherited the previous era's tradeoffs.
What follows is what each era got right — and what it left on the table.
The problem isn't HTML or CSS. The problem is that cross-file consistency has no native solution.
Give the engine your data, let it correlate it.
The CMS has to service every single request. This creates:
Following the popularity of APIs: CMS stores your data, frontend fetches and renders asynchronously.
In practice: for the elite alone. Most agencies can't deliver headless at WordPress prices.
We're back to publishing static HTML. This time, the generator handles site-wide elements, so we get the CMS's structural wins without the runtime liability.
The visual builder problem remains unsolved at the static-generator layer.
To explain how, we need to revisit something every web developer takes for granted.
The web platform incorporates three distinct elements — and the boundaries between them are where complexity lives.
The first stake. Meant to be semantic. We thought this was all we needed, then people wanted it to look nice.
A good solution, very different from HTML. Left us to keep our classes organized — lots of work. Good to have looks, then people wanted to do things.
A novel programming language. Limitless possibilities for interactivity, but with lots of manual wiring through the DOM.
It's the plumbing between them.
There's no single paradigm that integrates structure, style, and behavior natively. Every framework since 1995 has been inventing plumbing — and every visual builder has been trying to model that plumbing without inventing lock-in.
This is why no general-purpose visual builder for the web platform exists today. It's not for lack of trying.
React, Vue, Svelte, Solid — they nudge us in the right direction:
But none of them gives a truly integrated model for structure, style, and scripting.
CSS lives in a separate file (or a styled-components abstraction, or a Tailwind class string). Scripts live in <script> tags or .js exports. The composability gap is closed by convention, not by the model.
A visual builder operating on React still has to invent its own intermediate representation. That's lock-in by construction.
The DOM already integrates structure, style, and behavior. With no extra plumbing.
The DOM can be serialized to represent the intended running state of a website or application.
If your source of truth is the DOM itself, expressed as data, the composability problem evaporates.
Structure, style, behavior, reactivity — one tree, one file, one source of truth.
A visual builder operating on this has almost no novel connectivity to track. Every mutation is a direct edit on the DOM-as-data.
{
"tagName": "my-counter",
"state": {
"count": 0,
"increment": { "$prototype": "Function", "body": "state.count++" }
},
"style": {
"display": "flex",
"gap": "1rem",
":hover": { "background": "var(--surface-hover)" }
},
"children": [
{ "tagName": "span", "textContent": "${state.count}" },
{ "tagName": "button", "textContent": "+",
"onclick": { "$ref": "#/state/increment" } }
]
}Five years ago, this idea would have required inventing half a dozen primitives. Today, the web platform ships them all.
| Capability | What it enables |
|---|---|
| Web Components API | Encapsulation of structure / style / scripting, with slot composition for nesting |
| CSS Custom Properties | Site-wide style inheritance without specialized class systems |
| CSS Nesting | Group CSS rules with elements instead of classes |
| Template Literals | Unified, standards-driven syntax for dynamic content |
| Signals (TC39) | A standard reactive pattern, on track to become part of the language |
| Git | A 17-year-old proven model for collaborative, code-based site development |
Jx is the connective tissue. We're not inventing primitives — we're connecting the ones the browser already ships.
Markdown deserves its own slide in this story.
We can compose via text files and publish for AI ingestion and ranking. Content as code, version-controlled in git.
Jx combines:
The workflow:
Visually in Studio, or by hand in any editor.
The commit is the deploy trigger.
The site compiles and publishes automatically to a CDN.
anything the web platform can do, you can build
content from markdown, JSON, CSV, external APIs, server functions, whatever
JSON Schema 2020-12 dialect, MIT licensed, plain HTML output
no database, no PHP runtime, no plugin marketplace, no proprietary IR
Five interfaces, one document model.
All operating on the same .json and .md files. No proprietary state, no hidden database.
What you can promise your developers:
@vue/reactivity under the hood (signals coming when the proposal lands)timing: "server" for the cases that need it, bundled per-adapter (Cloudflare today, Netlify/Vercel/Node next)$srcIf Jx disappeared tomorrow, your sites would keep running. The JSON is human-readable, the output is standard web.
— A technical pitch · 2026 —
Build modern websites and apps with modern web APIs — visually, with a high ceiling, without the legacy tax.