hnq.me
all concepts
client Updated 2026-07-09 Step 4 of 6

Runtime JS

A beginner-friendly guide to runtime JS and runtime-driven UI.

On this page 2026-07-09

A beginner-friendly guide to runtime JS: the small browser runtime that makes HTML respond to state, events, directives, and user input.

Runtime JS is about behavior after HTML reaches the browser.

The page already exists. Runtime JS makes it alive.

HTML -> runtime JS -> behavior

Table of Contents

The Simple Idea

Runtime JS means the interface can respond after the server has sent HTML.

Example:

count = 0
click button
count = 1
text updates

You do not manually rewrite every part of the DOM.

The system connects state to the view.

Why Runtime JS Exists

Interactive pages have changing state.

Examples:

  • form values,
  • counters,
  • filters,
  • selected tabs,
  • dropdowns,
  • carts,
  • validation,
  • loading states,
  • live data.

Without a runtime JS model, you manually update the DOM everywhere.

Runtime JS makes updates feel connected while keeping the page close to HTML.

State And View

Runtime JS starts with two ideas:

state = what the app knows
view = what the user sees

When state changes, the view should match.

The hard part is keeping them in sync without writing too much glue code.

The Runtime JS Loop

The loop:

read state
render view
user acts
update state
render again

Different systems implement this differently.

Some use virtual DOM.

Some use signals.

Some track dependencies.

Some compile templates.

Some walk expressions in the DOM.

The goal is similar:

make UI follow state

Why It Feels Good

A runtime-driven UI feels good because it reduces manual DOM work.

Instead of saying:

find this element
set this text
hide that element
disable this button

you can say:

this text depends on count
this element shows when open is true
this input writes to email

That is a powerful shift.

Where It Gets Heavy

Runtime JS systems can become heavy when a project needs:

  • build tools,
  • bundlers,
  • large dependencies,
  • hydration,
  • client-side routing,
  • state libraries,
  • complex component trees,
  • duplicated server/client rules.

This does not make Runtime JS bad.

It means every model has a cost.

Runtime Instead Of Framework

One alternative is a smaller runtime.

Instead of writing a full client app, HTML can stay the main surface.

Small directives and expressions describe the dynamic parts:

<button data-click="count = count + 1">+</button>
<b data-text="count"></b>

This is still Runtime JS in spirit.

The shape is different:

HTML first
small expressions
runtime handles updates
less client app structure

KitJS And Kitwork Notes

This concept comes directly from KitJS. Before I called it runtime JS, I was mostly thinking about reactive behavior: state changes, DOM updates, directives, model binding, validation, and small UI interactions.

KitJS taught me that a page does not always need a full frontend framework. Sometimes it needs a tiny runtime that can read the HTML, understand a few directives, and keep behavior close to the element.

Kitwork pushed that idea into a larger system. Runtime JS became the client side of a server-rendered runtime: the server owns truth and rendering, while the browser receives just enough behavior to make the page feel alive.

My Learning Notes

I learned Runtime JS before I started thinking deeply about runtime.

At first, reactive JavaScript felt like the natural answer:

state changes
UI updates
components organize everything

That model taught me a lot.

Later I became more interested in a smaller question:

how much interactivity can stay inside HTML before I need a full client app?

That question pushed me toward KitJS-style runtime.

The lesson:

Runtime JS is the idea
framework is one expression of the idea
runtime can be another

Common Misunderstandings

"Runtime JS means React."

No. React is one popular library. Runtime JS programming is a broader idea.

"Runtime JS always means client-side app."

No. Runtime JS ideas can appear in small runtimes, templates, signals, spreadsheets, and server-driven systems.

"Moving away from a framework means abandoning runtime JS."

No. You can keep the idea and change the surface.

Previous: behavior

Next: hydrate

Related: expression, evaluate, servertruth

Search