DEV Community: bunzzeok

Can a Compiler-First Framework Scale to Real Apps Without Reinventing React?

bunzzeok — Sat, 22 Aug 2026 11:26:05 +0000

A few weeks ago, I wrote about Kudzu, an open-source compiler-first web framework that lets you write familiar React-shaped TypeScript/TSX without shipping React, a VDOM, or hydration by default.

The original idea is straightforward:

write familiar TSX
analyze components, state, events, lists, effects, and dependencies at build time
emit complete HTML
ship only the JavaScript capabilities a page actually needs

That part works.

But I think the more interesting problem starts after that.

Static pages were never the hard part

A compiler can make a static page extremely small.

That does not automatically make it a serious application framework.

The real question is:

Can Kudzu grow into something capable of building large, long-lived applications without eventually recreating the same generic runtime model it was designed to remove?

By “real applications,” I mean things like:

shared application state
async/server data
loading and error states
cache invalidation
optimistic mutations
complex forms
nested routing
authentication and permissions
realtime updates
large lists and virtualization
editors
charts and maps
code splitting
long-lived application state

If Kudzu cannot handle those well, then it risks ending up as a very good static-site compiler with some interactivity.

That is not the goal.

The goal is not zero JavaScript

This distinction matters.

I do not think a serious web application should avoid client-side JavaScript at all costs.

A dashboard may genuinely need:

shared state
navigation
server data
caching

A chat application may genuinely need:

WebSocket connections
keyed lists
lifecycle management
optimistic updates

An editor may need a substantial JavaScript library.

That is fine.

The goal is not:

zero JavaScript

The goal is closer to:

zero JavaScript that exists only because the framework needs it

A static route might ship almost nothing.

A complex application route might ship much more.

But that code should correspond to capabilities the application actually uses.

Where I do not want Kudzu to go

There are two easy ways to make compatibility grow quickly.

I think both are dangerous.

1. Rebuild React underneath Kudzu

The simplest escape hatch would be to add:

a generic component tree
VDOM reconciliation
hydration
a generic rerender loop
a React-compatible fallback runtime

That would make more React code easier to support.

But it would also erase much of the reason Kudzu exists.

The architecture I want to preserve is closer to:

state change
    ↓
known dependency
    ↓
specific DOM / resource / list update

instead of:

state change
    ↓
component rerender
    ↓
virtual tree
    ↓
diff
    ↓
DOM update

2. Add endless compiler special cases

The other failure mode is less obvious.

It looks like this:

React Router special case
→ Zustand special case
→ TanStack Query special case
→ React Hook Form special case
→ MUI special case
→ browser API special case
→ ...

That may work for a while.

But eventually the compiler becomes a catalog of package-specific syntax patterns.

Then users are no longer writing normal React-shaped code.

They are writing:

“the specific shape Kudzu happens to understand”

That is also a problem, especially for AI-assisted development.

If an AI agent constantly has to read compiler limitations, rewrite source into special forms, retry builds, and search framework docs, the token savings disappear.

The direction I am exploring

The architecture I am currently leaning toward has three layers.

React / npm ecosystem source
            ↓
compatibility / normalization
            ↓
small Kudzu application model
            ↓
compiler
            ↓
HTML + only required runtime capabilities

The important part is the middle.

Kudzu needs a small set of application capabilities that are powerful enough to build serious applications.

Not hundreds of framework-specific features.

Something closer to:

local state
shared state
derived values
events
async resources
mutations
navigation
keyed/owned DOM ranges
lifecycle
external UI instances
lazy capabilities

The exact list is still something I am working through.

The goal is that a small number of primitives can be composed into many different applications.

What about third-party libraries?

I do not think Kudzu should try to compile the internals of every library.

Some packages should simply run normally.

For example:

Zod
date-fns
Dexie
Three.js
MapLibre

If a library already owns a canvas, WebGL context, or DOM subtree, Kudzu may only need to manage:

mount
update
dispose
lifetime

For example:

Kudzu
  └─ map container
       └─ MapLibre owns the internals

No VDOM is required for that.

The same idea may work for:

CodeMirror
Monaco
ProseMirror
Chart.js
ECharts
data grids
media players

This is very different from embedding a React island.

Kudzu would not try to recreate the package's internal rendering model.

It would only own the boundary.

React ecosystem compatibility still matters

I do want practical React migration compatibility.

But I think there is an important distinction between:

React runtime compatibility

and:

React source compatibility

The long-term goal is closer to:

maximize React ecosystem source compatibility while minimizing React runtime compatibility

That means different packages may need different strategies.

Native

Normal JavaScript/TypeScript packages can run as-is.

Compiled

Some familiar React-shaped patterns can be understood and compiled away.

Normalized

Some source can be transformed into simpler HTML/JavaScript/Web API code before it reaches the core compiler.

For example:

<Link to="/users">Users</Link>

could conceptually become:

<a href="/users">Users</a>

Adapter

Some libraries may need package-specific migration logic.

External owned UI

Some complex UI libraries can own a bounded DOM/canvas area.

Partial or unsupported

Some React libraries may rely deeply on React reconciliation or component-tree semantics.

I think it is better to explicitly say “unsupported” than silently fall back to a React runtime.

Performance so far

There are two sets of performance evidence I have been using.

The public cross-framework benchmark currently uses an earlier Kudzu version, so I do not treat it as a current-version benchmark.

Still, it is useful for understanding the architecture.

On a commerce fixture under Slow 4G + 4× CPU throttling, the published results included:

Kudzu first interactive listing: 450ms
Astro: 2.22s
TanStack Start: 2.90s
React Router: 2.96s
Next.js App Router: 3.54s

Kudzu did not win everything.

The 3-step form benchmark exposed a clear weakness in cross-page state propagation:

TanStack: 191ms
Astro: 196ms
React Router: 395ms
Next.js: 365ms
Kudzu: 700ms

I think that loss is useful.

It shows exactly the kind of application-level problem that matters more than shaving another few hundred bytes off a bundle.

Kudzu's own maintained performance evidence also showed a stateful capability bundle substantially smaller than React/Vue/Svelte in that specific fixture, and large generated-route builds scaling competitively into the thousands of routes.

I do not consider any of those numbers universal proof.

They are fixture-specific.

The part I care about most now is whether those characteristics survive as application complexity increases.

The next test should not be another blog

I think the next serious test for Kudzu needs to be an actual application.

Something like a small Linear / GitHub Issues / Jira-style app with:

login
workspaces
shared state
nested routing
server data
loading/error states
caching
mutations
optimistic updates
forms
modals
search/filtering
realtime updates
a large list
lazy-loaded editor or chart

The goal is not to build another demo that happens to match the compiler.

The goal is to let the application expose where the compiler model is insufficient.

Then:

application fails
↓
identify the general missing capability
↓
check whether existing primitives can express it
↓
only add a new primitive if the limitation repeats across multiple real apps

That is the development loop I want to follow.

AI development is part of the design

There is another reason I care about keeping the application model small.

AI coding agents already understand React-shaped TypeScript/TSX extremely well.

I do not want Kudzu to replace that with an entirely new DSL or dozens of Kudzu-specific APIs.

Ideally an AI should be able to write familiar code while the compiler handles things the model should not need to reason about repeatedly.

That includes things like:

dependency tracking
unnecessary rerender semantics
framework boilerplate
some migration transformations
precise diagnostics

The metric I eventually want to measure is not just bundle size.

It is:

cost per successful task

For the same feature, using the same coding agent:

how many tokens were used?
how many files were opened?
how many build attempts?
how many compiler failures?
how many edits?
how much framework documentation had to be read?
did the final application actually behave the same?

If Kudzu uses less client JavaScript but makes the AI fight the compiler for twice as long, that is not a win.

Where Kudzu is now

Kudzu is still experimental.

The current work is moving increasingly toward application-level behavior rather than only static output.

But I do not think the large-application question is solved yet.

That is the part I am trying to figure out now.

The two constraints I am trying to hold at the same time are:

1. Do not rebuild React underneath the compiler.

2. Do not let “minimal runtime” prevent Kudzu from becoming a real application framework.

I think the interesting architecture is somewhere between those two extremes.

Project:

https://kudzujs.cloud

GitHub:

https://github.com/kudzujs/kudzu

Public benchmark:

https://github.com/SimYunSup/kudzu-based-bench

I'd be interested in hearing from people who have worked on large React, Vue, Svelte, Solid, or similar applications:

What browser-side capabilities do you consider genuinely unavoidable for serious web applications?

And which ones do you think mostly exist because of the rendering model of the framework you are using?

I Built the Same Commerce App in Kudzu, Astro, React Router, TanStack Start, and Next.js

bunzzeok — Tue, 18 Aug 2026 04:07:53 +0000

In my previous post, I introduced Kudzu, a compiler-first framework that turns a statically analyzable subset of React-shaped TSX into static HTML and route-specific JavaScript without shipping React, a virtual DOM, or a hydration runtime.

That raises an obvious question:

What happens when you move beyond counters and small demos?

So I built the same commerce application five times:

Kudzu
Astro + React islands
React Router
TanStack Start
Next.js App Router

The goal wasn't to create a synthetic benchmark where Kudzu could win.

I wanted to replay something closer to an actual user session and measure what the browser experiences.

The benchmark is open source:

https://github.com/SimYunSup/kudzu-based-bench

The fixture

Each implementation represents the same store with the same behavioral contract.

There are six routes covering:

home
search with filtering and sorting
collections
product details
policy/content
checkout

The interactive paths include product options, adding items to the cart, filtering, sorting, navigation into product pages, back navigation, and cart state.

All five versions emit complete HTML.

That matters because simply measuring when text becomes visible doesn't tell us much here.

The more interesting question is:

When does the page become reliably interactive, and what did the browser have to download to get there?

Why I didn't make this an LCP benchmark

LCP is useful, but it doesn't distinguish these implementations particularly well in this fixture.

The LCP element is generally a product image, and the image bytes are intentionally identical between implementations.

A framework benchmark where the dominant measurement is an identical image mostly tells us about the image.

Instead, I focused on observable application behavior:

contentReady: when the important content exists in the DOM
actReady: when a control actually works
stepLatency: successful interaction to next paint
navigation latency
dropped early clicks
bytes transferred across the session
JavaScript downloaded per route
behavior when JavaScript is delayed or partially unavailable

The browser is the judge.

I don't use framework-internal "hydration complete" signals.

Replaying an actual session

The main test runs under:

Slow 4G + 4× CPU slowdown

and replays the same interactions five times for each implementation.

The median results for initial listing interactivity were:

Framework	contentReady	actReady
Kudzu	170 ms	250 ms
Astro	223 ms	2,229 ms
TanStack Start	170 ms	2,859 ms
React Router	170 ms	2,957 ms
Next.js	178 ms	3,537 ms

The content itself appears at roughly the same time.

That's expected: every implementation ships complete HTML.

The large difference appears between seeing the interface and being able to reliably use it.

For Kudzu, the compiler-generated behavior is available after roughly 250 ms in this test.

For the React-based implementations, more client-side machinery has to arrive and execute first.

How much JavaScript reaches each route?

I also measured JavaScript from the browser's network activity rather than statically crawling the import graph.

That distinction turned out to matter.

For example, Astro can load island runtime code through dynamic imports that a naive static crawler can miss.

Here are the initial route-level JavaScript totals, gzip compressed:

Framework	Home	Search	Product	Checkout
Kudzu	4.7 KB	9.4 KB	4.9 KB	4.7 KB
Astro	60.6 KB	61.0 KB	61.1 KB	60.6 KB
TanStack Start	101.7 KB	101.7 KB	101.9 KB	101.3 KB
React Router	104.3 KB	104.2 KB	104.4 KB	103.9 KB
Next.js	134.2 KB	134.8 KB	133.8 KB	132.8 KB

This is the architectural difference I wanted to investigate when I started Kudzu.

Kudzu's search route needs keyed-list behavior, so it ships more JavaScript than the simpler routes.

The other routes don't pay for that capability.

The generated JavaScript follows what the route actually uses.

But SPA navigation wins somewhere else

I didn't want the benchmark to stop at initial page load.

The session opens a product using a real link, adds it to the cart, and then navigates back.

For listing → product navigation:

Framework	Navigation
TanStack Start	182 ms
React Router	185 ms
Astro	222 ms
Kudzu	271 ms
Next.js	360 ms

Here the SPA routers show a real advantage.

React Router and TanStack Start perform the transition faster than Kudzu's document navigation.

That's an important tradeoff.

Removing a persistent application runtime doesn't magically make every operation faster.

It changes where the costs occur.

What happens across the whole session?

I also measured all network transfer across the session, including prefetching.

Script transfer was:

Framework	Script transferred
Kudzu	34.4 KB
Astro	193.1 KB
TanStack Start	317.6 KB
React Router	322.3 KB
Next.js	455.5 KB

This is more interesting to me than a single initial bundle number.

Users don't experience isolated benchmark pages.

They enter an application, navigate, interact, reuse cached resources, and sometimes download things speculatively prefetched by the framework.

So the session should carry its cache forward too.

What if JavaScript arrives late?

I also wanted to test something performance benchmarks often ignore:

failure and degradation.

I tested six capabilities:

reading content
category navigation
entering a product
filtering
selecting an option
adding to cart

under three conditions:

JavaScript completely blocked
scripts delayed by two seconds
one script request lost

That gives 18 capability checks per implementation.

Results:

Framework	Surviving capabilities
Kudzu	15 / 18
Astro	12 / 18
TanStack Start	8 / 18
React Router	8 / 18
Next.js	8 / 18

None of them magically retain full interactivity without JavaScript.

But their failure modes are different.

That's something I want to explore much more deeply.

Kudzu also has a scaling problem

One result I don't want to hide is build scaling.

With 1,000 catalog items, median build times were approximately:

Framework	Build time
Astro	1.82 s
TanStack Start	2.47 s
React Router	3.07 s
Kudzu	3.56 s
Next.js	5.62 s

More importantly, Kudzu currently has the steepest scaling curve between 100 and 1,000 products.

That's a compiler architecture problem.

Kudzu currently emits capability modules per product in places where that work should be shared or amortized more effectively.

So while the runtime results are encouraging, I wouldn't call this proof that Kudzu scales to large applications.

It doesn't yet.

What I learned

The biggest takeaway for me isn't simply that "less JavaScript is faster."

That's too simplistic.

The more interesting result is that different architectures move cost to different places.

A compiler-first architecture can dramatically reduce the amount of framework machinery required in the browser.

But SPA routers can provide faster client-side navigation.

Compiler specialization can reduce route JavaScript.

But generating specialized artifacts can increase build cost as the application grows.

Avoiding hydration can make interactions available earlier under constrained networks.

But that doesn't automatically solve application architecture, state management, forms, routing, or ecosystem compatibility.

Those are the problems I'm working on next.

This still isn't a large-app benchmark

The commerce fixture is intentionally much larger than a toy benchmark, but I don't consider it evidence that Kudzu is ready for a truly large production application.

The next step is larger fixtures with:

shared state
async/server state
deeper component and module graphs
forms
authentication
more complex routing
broader React ecosystem integration

In fact, I've already started using separate form and documentation/search fixtures because the commerce benchmark doesn't expose every architectural weakness.

Some of those tests make Kudzu look much less flattering.

That's useful.

A benchmark should tell me where the architecture breaks, not just give me a chart I can put on a landing page.

If you're interested in compiler-first frontend architecture, I'd especially like feedback on the benchmark methodology and what kinds of real application behavior I should test next.

Benchmark repo:
https://github.com/SimYunSup/kudzu-based-bench

Kudzu:
https://github.com/kudzujs/kudzu

Kudzu: Compiling React-shaped TSX to Static HTML Without Hydration

bunzzeok — Thu, 06 Aug 2026 12:52:25 +0000

React-shaped TSX is a familiar way to describe user interfaces, but deploying it usually involves shipping a JavaScript runtime, hydration, or a client-side component tree.

I have been experimenting with a different approach through an open-source project called Kudzu.

Kudzu compiles a statically analyzable subset of React-shaped TypeScript and TSX into complete static HTML, CSS, and only the route-specific ESM capabilities actually used.

A small example

import { useState } from "@kudzujs/core"

export default function HomePage() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount(count + 1)}>
      Grown {count} times
    </button>
  )
}

The component executes during the build. It does not survive as a browser component.

Kudzu generates the initial HTML and lowers the state update into direct browser behavior. State setters update logical state synchronously, while DOM writes are batched at the end of the synchronous turn.

Static routes ship no JavaScript

When a route does not use browser interaction, Kudzu emits HTML and CSS without a client-side JavaScript runtime.

Interactive routes include only the capabilities they use, such as state bindings, event handlers, effects, keyed collections, or runtime URL parameters.

There is no React runtime, hydration pass, virtual DOM, or retained browser component tree.

This is not full React compatibility

Kudzu accepts only patterns that it can analyze and lower safely.

Supported patterns include function components, props, children, state, effects, conditions, keyed collections, refs, and selected React Router migration patterns.

Unsupported nearby patterns fail during the build with a source location and actionable diagnostic instead of silently falling back to React.

The project is experimental, and the supported TSX surface may change.

Why build it?

The goal is to explore whether ordinary React-shaped applications can be migrated to static deployment artifacts without forcing developers to rewrite declarative components as imperative DOM code.

Build-known work stays at build time. Browser code is generated only when the browser is the only place where the required value or interaction exists.

Try it

Documentation and demos: https://kudzujs.cloud

Source code: https://github.com/kudzujs/kudzu

npm: https://www.npmjs.com/package/@kudzujs/core

I would appreciate feedback on the compiler boundaries, generated runtime model, and ordinary React patterns that would be most valuable to support next.

How I compile React-shaped TSX without React or hydration

bunzzeok — Sat, 25 Jul 2026 12:23:04 +0000

I started building Kudzu while making static websites with AI.

AI coding tools have become very good at producing React-shaped TSX, and I have become used to reviewing code in that form. Function components, props, JSX, and event handlers are often easier for me to understand and verify than scattered DOM queries and imperative JavaScript mutations.

But I was still building static pages.

I wanted to keep TSX as the authoring and code-review format without automatically shipping React, a virtual DOM, hydration, or a browser-side component tree.

Kudzu grew from that idea:

Write familiar TSX, execute components during the build, and ship ordinary HTML with only the JavaScript each route actually needs.

Kudzu is an experimental, HTML-first TSX framework.

Website: kudzujs.cloud

GitHub: github.com/kudzujs/kudzu

The problem I wanted to solve

Consider a blog, documentation site, newsletter, or product landing page.

Most of the page is already known during the build:

headings;
navigation;
articles;
images;
metadata;
product descriptions;
documentation content.

TSX is a convenient way to author and review that structure.

function PostCard({ title, description, href }: {
  title: string
  description: string
  href: string
}) {
  return (
    <article>
      <h2><a href={href}>{title}</a></h2>
      <p>{description}</p>
    </article>
  )
}

The component model is useful for authoring, but that does not necessarily mean the browser needs a component runtime.

For a static page, I wanted the output to remain ordinary HTML.

<article>
  <h2><a href="/posts/hello">Hello</a></h2>
  <p>My first article.</p>
</article>

I also wanted interactive pages to receive only the JavaScript required for their actual behavior.

Kudzu's model

Kudzu treats components as build-time authoring units.

React-shaped TSX
        ↓
Kudzu compiler
        ↓
Static HTML + CSS + capability-specific ESM

Function components execute during the build.

The browser does not receive:

the component functions;
React;
a virtual DOM;
a hydration pass;
a retained component tree;
a general rerender loop.

A completely static route receives no client JavaScript.

A static page

A Kudzu page lives in src/pages.

// src/pages/index.tsx

export default function HomePage() {
  return (
    <main>
      <h1>Hello from Kudzu</h1>
      <p>This page becomes static HTML.</p>
    </main>
  )
}

Build the project:

npm run build

The output is written to dist.

dist/
├─ index.html
└─ assets/
   └─ style.css

Because the page has no browser behavior, Kudzu does not add a JavaScript runtime.

Adding state

Kudzu supports a React-shaped useState API.

import { useState } from "@kudzujs/core"

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  )
}

The compiler identifies:

the logical state;
the setter;
the event;
the text node bound to the state.

The component is executed during the build to produce the initial HTML.

The browser receives a small behavior plan that updates the relevant DOM node directly.

click
  → update logical state
  → queue a DOM commit
  → patch the bound text node

The browser does not rerun the component.

Immediate logical state

Kudzu deliberately differs from React's state snapshot behavior.

function increaseTwice() {
  setCount(count + 1)
  setCount(count + 1)
}

In Kudzu:

A setter updates logical state immediately.
The next statement reads the latest logical value.
Setters run in source order.
DOM writes are batched until the synchronous turn ends.

The handler above increments the value by two and patches the DOM once.

This model gives event handlers normal sequential JavaScript behavior without requiring a browser component rerender.

Simple commands and normal JavaScript

Kudzu has two event compilation paths.

Simple setter-only handlers compile to compact behavior commands.

<button onClick={() => setCount(count + 1)}>
  Increase
</button>

Normal synchronous or asynchronous handlers compile to external ESM.

async function loadStatus() {
  setStatus("loading")

  try {
    const response = await fetch("/api/status")
    const result = await response.json()
    setStatus(result.status)
  } catch {
    setStatus("failed")
  }
}

Kudzu does not use:

eval;
new Function;
inline executable JavaScript;
hydration.

Relative TypeScript helpers can also be bundled into the generated handler module.

import { normalizeStatus } from "../lib/status"

async function loadStatus() {
  const response = await fetch("/api/status")
  const result = await response.json()

  setStatus(normalizeStatus(result))
}

Direct DOM bindings

State can be used in text, attributes, styles, and form properties.

const [open, setOpen] = useState(false)

return (
  <button
    className={open ? "active" : "idle"}
    aria-expanded={open}
    onClick={() => setOpen(!open)}
  >
    {open ? "Close" : "Open"}
  </button>
)

Kudzu compiles the expressions into direct DOM updates.

open changes
  → patch class
  → patch aria-expanded
  → patch text

The entire component is not rerendered.

Conditional DOM

Inline conditional children compile to bounded DOM ranges.

const [open, setOpen] = useState(false)

return (
  <>
    <button onClick={() => setOpen(!open)}>
      Toggle menu
    </button>

    {open && (
      <nav>
        <a href="/docs">Docs</a>
        <a href="/example">Examples</a>
      </nav>
    )}
  </>
)

Both branches are prepared during the build. The browser mounts or removes only the relevant DOM range.

There is still no virtual DOM or component tree.

Keyed lists

Kudzu also supports a constrained form of keyed list rendering.

const [items, setItems] = useState([
  { id: 1, name: "Oak" },
  { id: 2, name: "Pine" }
])

return (
  <ul>
    {items.map(item => (
      <li key={item.id}>
        {item.name}
        <button
          onClick={() =>
            setItems(items.filter(entry => entry.id !== item.id))
          }
        >
          Remove
        </button>
      </li>
    ))}
  </ul>
)

The initial list is emitted as static HTML.

When state changes, Kudzu moves, inserts, updates, or removes the keyed DOM nodes directly.

Existing keyed nodes are preserved instead of remounted.

Build-time data

Async components can load data during the build.

export default async function ProductsPage() {
  const products = await fetch(
    "https://example.com/api/products"
  ).then(response => response.json())

  return (
    <main>
      <h1>Products</h1>

      <ul>
        {products.map(product => (
          <li>{product.name}</li>
        ))}
      </ul>
    </main>
  )
}

When the route and data are available during the build, the result is complete static HTML.

No browser fetch or hydration is required.

Dynamic static routes

Build-known dynamic routes use getStaticPaths().

// src/pages/posts/[slug].tsx

export function getStaticPaths() {
  return [
    {
      params: { slug: "hello-kudzu" },
      props: { title: "Hello Kudzu" }
    },
    {
      params: { slug: "static-html" },
      props: { title: "Static HTML" }
    }
  ]
}

export default function Post({
  title
}: {
  title: string
}) {
  return <h1>{title}</h1>
}

The build produces:

dist/posts/hello-kudzu/index.html
dist/posts/static-html/index.html

The result can be deployed to an ordinary static host.

Browser-only effects

Sometimes data or browser APIs are only available after the document loads.

Kudzu supports a deliberately constrained useEffect form.

import { useEffect, useState } from "@kudzujs/core"

export default function StatusPage() {
  const [status, setStatus] = useState("loading")

  useEffect(() => {
    fetch("/api/status")
      .then(response => response.json())
      .then(result => setStatus(result.status))
  }, [])

  return <p>Status: {status}</p>
}

The effect is not executed during static rendering.

Kudzu emits a route-specific effect entry that updates the existing logical state and bound DOM nodes.

The component itself is not shipped or rerun.

Capability-specific output

Kudzu does not give every interactive route the same runtime.

A route receives only the capabilities it uses.

Static route          → HTML only
State commands        → compact behavior runtime
Reactive bindings     → binding capability
Conditional DOM       → bounded DOM operations
Keyed lists           → list capability
Normal handlers       → external handler ESM
Effects               → route-specific effect entry
Runtime parameters    → route-specific pathname reader

A static route remains JavaScript-free even if another route in the same project is interactive.

Static output and Cloudflare

Kudzu writes deployable artifacts to dist.

A minimal Cloudflare configuration looks like this:

{
  "name": "my-kudzu-site",
  "compatibility_date": "2026-07-20",
  "assets": {
    "directory": "dist"
  }
}

Build and deploy:

npm run build
npx wrangler deploy

The Kudzu website itself is deployed using Cloudflare static assets.

The project also uses build-time generation for:

canonical URLs;
sitemap entries;
robots metadata;
structured data;
static blog routes.

Why not just write vanilla JavaScript?

Vanilla JavaScript is not the problem.

For small behavior, it is often the smallest and best browser output.

The problem I was trying to solve was authoring and review.

When working with AI-generated code, I found this form easier to inspect:

<PostCard
  title={post.title}
  description={post.description}
  href={`/posts/${post.slug}`}
/>

than a collection of unrelated operations:

const article = document.createElement("article")
const heading = document.createElement("h2")
const link = document.createElement("a")

link.href = `/posts/${post.slug}`
link.textContent = post.title
heading.append(link)
article.append(heading)

The browser may ultimately need ordinary DOM operations.

I just did not want to author and review the entire site at that level.

Kudzu uses TSX as the input language and ordinary HTML and DOM operations as the output.

What Kudzu is not

Kudzu is not a drop-in React replacement.

It supports a statically analyzable React-shaped subset.

Unsupported patterns fail during the build instead of silently causing Kudzu to ship a general component runtime.

Kudzu currently does not provide:

arbitrary React package compatibility;
a virtual DOM;
request-time SSR;
server actions;
a default SPA router;
Suspense semantics;
concurrent rendering;
a general browser component rerender loop.

The goal is not to run every React application unchanged.

The goal is to preserve familiar TSX authoring where it can be compiled safely into static HTML and direct browser behavior.

Current status

Kudzu is experimental, and the supported TSX surface may still change.

The current implementation includes:

function components;
props and children;
fragments;
static and dynamic routes;
async build-time components;
primitive and serializable object state;
reactive text and attributes;
controlled form properties;
conditional DOM;
keyed lists;
context;
DOM refs;
synchronous and asynchronous handlers;
relative TypeScript helpers;
mount effects;
primitive effect dependencies;
runtime path parameters;
Cloudflare static deployment.

I am especially interested in feedback about:

the compiler model;
migration from conventional React-shaped code;
unsupported patterns that need better diagnostics;
generated JavaScript size;
immediate logical state semantics;
real static-site use cases.

Try Kudzu

Create a project:

npm create kudzu@latest my-app
cd my-app
npm run dev

Build the static output:

npm run build

The generated files are available in:

dist/

The build execution plan is available in:

.kudzu/kudzu-plan.json

Links

Website: https://kudzujs.cloud/

Examples: https://kudzujs.cloud/example

Documentation: https://kudzujs.cloud/docs

GitHub: https://github.com/kudzujs/kudzu

npm: https://www.npmjs.com/package/@kudzujs/core