Build a tiny reactive UI

A tiny framework in one page

You have already studied closures, Proxy, Reflect, observer-style signals, state management, microtasks, DOM modification, delegation, event delegation, MutationObserver, and application architecture. This capstone combines them into a real, tiny UI framework.

The framework is intentionally small: one reactive function, one virtual-node helper, one patcher, and one delegated event listener. It is not a replacement for React, Vue, Svelte, or Solid. It is a microscope for seeing the loop those tools automate.

This lesson also points forward to Build a jQuery-style library for packaging small APIs and to XSS for the security lesson that follows from unsafe rendering.

The reactive(obj) wrapper stands in front of an object. Reads go through get; writes go through set. The set trap forwards with Reflect.set, then schedules a render. A queued flag keeps several assignments in the same call stack from causing several renders.

1const cache = new WeakMap();2let queued = false;3let renders = 0;4const writes = [];5 6function reactive(target) {7  const wrap = (value) => {8    if (typeof value !== "object" || value === null) return value;9    if (cache.has(value)) return cache.get(value);10    const proxy = new Proxy(value, {11      get(target, property, receiver) {12        return wrap(Reflect.get(target, property, receiver));13      },14      set(target, property, value, receiver) {15        writes.push(String(property));16        const ok = Reflect.set(target, property, value, receiver);17        if (ok) scheduleRender();18        return ok;19      },20    });21    cache.set(value, proxy);22    return proxy;23  };24  return wrap(target);25}26 27function scheduleRender() {28  if (queued) return;29  queued = true;30  queueMicrotask(() => {31    queued = false;32    renders += 1;33    console.log("render " + renders + ": " + state.count + "/" + state.user.name + "/" + state.items.join("|"));34  });35}36 37const state = reactive({ count: 0, user: { name: "Ada" }, items: [] });38state.count += 1;39state.user.name = "Grace";40state.items.push("mutated");41state.items = ["replaced"];42console.log("sync renders " + renders);43queueMicrotask(() => {44  console.log("after microtask " + renders);45  console.log(writes.join(","));46});

Read the important lines in order. Line 10 creates the proxy. Line 14 sees every write, line 17 schedules rendering, and line 28 refuses to queue a second render. Lines 38 through 41 prove direct property assignment, nested assignment, array mutation, and direct array replacement all reach a trap.

1const cache = new WeakMap();Run2let renderQueued = false;3let renderCount = 0;4 5function reactive(target) {6  const wrap = (value) => {7    if (typeof value !== "object" || value === null) return value;8    if (cache.has(value)) return cache.get(value);9    const proxy = new Proxy(value, {10      get(target, property, receiver) {11        return wrap(Reflect.get(target, property, receiver));12      },13      set(target, property, value, receiver) {14        const ok = Reflect.set(target, property, value, receiver);15        if (ok) scheduleRender();16        return ok;17      },18    });19    cache.set(value, proxy);20    return proxy;21  };22  return wrap(target);23}24 25function scheduleRender() {26  if (renderQueued) return;27  renderQueued = true;28  queueMicrotask(() => {29    renderQueued = false;30    render();31  });32}33 34function render() {35  renderCount += 1;36  console.log("render " + renderCount);37}38 39const state = reactive({ count: 0, profile: { name: "Ada" }, items: [] });40render();41state.count += 1;42state.profile.name = "Grace";43state.items.push("Learn diffing");44state.items = ["Ship tiny UI"];45queueMicrotask(() => console.log("final renders " + renderCount));

Signals from the observer pattern lesson are more fine-grained: a computation records exactly which signal it read and only that computation re-runs. Our Proxy version is coarse: any state write schedules the whole view. That is simpler to build and easier to inspect, but it can do more work.

A view function should be boring: state in, description out. The h(tag, props, ...children) helper returns a lightweight object. It does not create a DOM node yet, so it is safe to call during a render pass and easy to compare later.

1function h(tag, props = {}, ...children) {2  return { tag, props, children: children.flat() };3}4 5function view(state) {6  return h(7    "section",8    { class: "todo-card" },9    h("h2", {}, "Count: ", state.count),10    h("button", { type: "button", "data-action": "increment" }, "+1"),11    h("ul", {}, state.items.map((item) => h("li", {}, item.title)))12  );13}14 15const state = { count: 1, items: [{ title: "Render with text nodes" }] };16console.log(JSON.stringify(view(state), null, 2));

Line 1 defines the tiny template helper. Line 5 names the view. Line 8 creates a heading with text children. Line 9 puts behavior metadata in data-action, not a callback. Line 10 maps data to list items. The final log shows plain JSON-like objects, not DOM nodes.

Mounting turns that tree into real DOM. Text children become Text nodes. Element children become document.createElement calls with attributes and child nodes. Notice that user text is never concatenated into innerHTML.

1function createDom(vnode) {2  if (typeof vnode === "string" || typeof vnode === "number") {3    return document.createTextNode(String(vnode));4  }5  const element = document.createElement(vnode.tag);6  for (const [name, value] of Object.entries(vnode.props ?? {})) {7    element.setAttribute(name, String(value));8  }9  for (const child of vnode.children) element.append(createDom(child));10  return element;11}12 13const userText = "<img src=x onerror=alert(1)>";14const tree = { tag: "p", props: {}, children: ["Hello ", userText] };15const root = document.querySelector("#app");16root.replaceChildren(createDom(tree));17console.log(root.textContent);18console.log(root.querySelector("img"));

Replacing the whole root is easy, but it loses browser-owned state: focus, selection, scroll positions, media playback, and uncontrolled input values. A patcher compares old and new virtual nodes, then mutates the existing DOM node when it can.

1function patch(oldVNode, newVNode, domNode) {2  if (typeof oldVNode !== "object" || typeof newVNode !== "object") {3    if (String(oldVNode) !== String(newVNode)) domNode.nodeValue = String(newVNode);4    return domNode;5  }6 7  if (oldVNode.tag !== newVNode.tag) {8    const replacement = createDom(newVNode);9    domNode.replaceWith(replacement);10    return replacement;11  }12 13  updateProps(domNode, oldVNode.props, newVNode.props);14  const oldChildren = oldVNode.children;15  const newChildren = newVNode.children;16  const shared = Math.min(oldChildren.length, newChildren.length);17 18  for (let index = 0; index < shared; index += 1) {19    patch(oldChildren[index], newChildren[index], domNode.childNodes[index]);20  }21  for (let index = shared; index < newChildren.length; index += 1) {22    domNode.append(createDom(newChildren[index]));23  }24  for (let index = oldChildren.length - 1; index >= newChildren.length; index -= 1) {25    domNode.childNodes[index].remove();26  }27  return domNode;28}

The patch has five jobs. Text nodes update nodeValue. Different tags are replaced. Props are changed or removed. Shared child indexes recurse. Extra children are appended or removed from the end. That is enough to understand the core loop, not enough to be production-ready.

1function view(count, status) {Run2  return h("section", {},3    h("h2", {}, "Count: " + count),4    h("label", {}, "Draft ", h("input", { placeholder: "keeps value" })),5    h("p", { class: "status", "data-status": status }, status),6  );7}8 9const root = document.querySelector("#app");10let oldTree = view(0, "idle");11root.replaceChildren(createDom(oldTree));12const input = root.querySelector("input");13input.value = "still typing";14input.focus();15 16const nextTree = view(1, "saved");17patch(oldTree, nextTree, root.firstChild);18oldTree = nextTree;19console.log(root.querySelector("input") === input);20console.log(document.activeElement === input);21console.log(input.value);

The replay uses a mutation counter inside the renderer: created nodes, text changes, attribute changes, replacements, and child inserts/removals. A real browser MutationObserver could count external mutations too, but counting our own operations makes the patch decisions explicit.

Keyed lists fix the classic reorder bug

Index-based diffing assumes the first old child corresponds to the first new child. That is false when a list reorders. The demo below intentionally shows the bug: an input value typed for item A appears under item B because the DOM node at index 0 was reused for the new item at index 0.

1const root = document.createElement("div");2const before = h("ul", {},3  h("li", { "data-id": "a" }, h("span", {}, "A"), h("input", {})),4  h("li", { "data-id": "b" }, h("span", {}, "B"), h("input", {})),5);6root.append(createDom(before));7root.querySelector("input").value = "typed for A";8 9const after = h("ul", {},10  h("li", { "data-id": "b" }, h("span", {}, "B"), h("input", {})),11  h("li", { "data-id": "a" }, h("span", {}, "A"), h("input", {})),12);13patch(before, after, root.firstChild);14const firstRow = root.querySelector("li");15console.log(firstRow.querySelector("span").textContent + ":" + firstRow.querySelector("input").value);

A keyed patch would build a map from stable keys such as data-id to old DOM nodes, move matching nodes to the new order, and create or remove only missing keys. Real frameworks invest heavily in this because forms and animations depend on identity.

The view creates buttons every render, but the framework does not bind listeners to those buttons. Instead, one listener stays on the root. It uses event.target.closest("[data-action]") to find the command element and root.contains to guard the boundary.

Delegation is not magic. It works because click events bubble. It can be blocked by stopPropagation(), and not every event bubbles. For focus, use focusin or capture, as the dedicated event delegation lesson explains.

The playground mounts the real tiny framework into an empty DOM node. Try three synchronous writes: two counter assignments and one array push happen before the microtask, yet the render count rises by one. Then replace the todo array to prove direct assignment works too.

1const root = document.querySelector("#app");2root.addEventListener("click", (event) => {3  const button = event.target.closest("[data-action]");4  if (!button || !root.contains(button)) return;5 6  if (button.dataset.action === "increment") {7    state.count += 1;8  }9  if (button.dataset.action === "toggle") {10    const todo = state.todos.find((item) => item.id === Number(button.dataset.id));11    if (todo) todo.done = !todo.done;12  }13});

const app = mountTinyReactiveUi(document.querySelector("#app"), (snapshot) => {
  console.log(snapshot.renderCount + ":" + snapshot.count + ":" + snapshot.todos.join("|"));
});
app.burst();
queueMicrotask(() => {
  app.replaceTodos();
  queueMicrotask(() => app.destroy());
});

The app's flow is the architecture loop from the previous lesson: input event → state change → scheduled render → new virtual tree → patch → stable DOM. The root listener is the controller edge. The view is a pure description. The state object is the single source of truth.

What real frameworks add

Our framework is a teaching tool. It has no component model, no lifecycle cleanup, no keyed diff, no hydration, no error boundary, no accessibility warnings, no compiler, and no devtools. Real frameworks add those layers because production UI has to survive partial failures, streaming data, forms, animations, and thousands of nodes.

Fine-grained reactive systems such as signals can skip a whole-tree virtual DOM pass by tracking exactly which DOM binding or computation read each value. Virtual DOM systems often trade that precision for simple views and strong component composition. Both are valid designs when the trade-offs are explicit.

Misconceptions

• “Proxy makes every nested object reactive immediately.” Not in this design. Nested objects are wrapped lazily when read.
• “Array mutation cannot be reactive.” Array methods write indexes and length through the proxy. Direct replacement also works through the parent property.
• “Virtual DOM means HTML strings.” A virtual node is a data object. DOM creation can and should use text nodes for user data.
• “Diffing always preserves identity correctly.” Index diffing preserves positions, not items. Reordered lists need keys.
• “One delegated listener is always better.” A single stable button is fine with a direct listener. Delegation shines for repeated or dynamic children.

Key takeaways

• A Proxy can schedule rendering from writes while Reflect preserves normal assignment behavior.
• queueMicrotask batches several synchronous state writes into one render of the latest state.
• Virtual nodes are plain descriptions; safe DOM creation uses elements, attributes, and text nodes instead of parsing user data as HTML.
• A patch function updates text, props, replacements, and children while preserving DOM nodes that still match.
• Index diffing is not enough for reordered lists; real frameworks use keys to preserve item identity.
• Event delegation keeps re-rendered and newly added controls working through one stable root listener.

One-line summary: a reactive UI framework turns state writes into scheduled view descriptions, then patches the smallest useful part of the DOM.

Up next: XSS, where the safe text-rendering rule becomes a full security practice.