Hara for Web Devs

Use Hara when your web application is hard to inspect

A web application can become difficult to understand long before it becomes large. State moves through components, stores, workers, APIs, and caches; events pass through layers; effects run after rendering; remote updates arrive at unpredictable times. Source shows what should happen, not the current state that exists in the running application.

Hara adds a live kernel to the application: a model you can inspect and change while the application runs. React can still render the UI and TypeScript can still handle browser integration.

◉Hara application modelNamed state, operations, events, and inspectable runtime values.

↓

⚛React interfaceInput, local interaction detail, and rendered views.

Work with the running application

Most web development begins in source: edit a file, wait for reload, repeat an action, inspect the UI. That works for visible changes; it is indirect when the problem depends on current state, pending work, or event order.

Files first

1. EditChange source.
2. ReloadWait for the application.
3. RepeatRecreate the interaction.
4. InspectInfer what happened.

Live model first

1. InspectRead the current model.
2. EvaluateCall one operation.
3. ObserveSee the returned value.
4. SaveKeep the verified definition.

This is REPL-driven development in the browser: inspect the current model, evaluate one operation, observe the result, then save the successful change in source.

Connect the REPL to the application model

A REPL is not only a place to test isolated expressions. It can connect you to the current application model.

(def project
  (atom {:status :ready
         :items []
         :selection nil}))

(defn add-item! [item]
  (swap! project update :items conj item))

(add-item! {:id "item-1" :title "First item"})
(deref project)

You do not need to click through the UI to test an operation: call it directly, then let the UI render the result.

Hara application
model→Named
operationUI
adapterReact
render

Keep the model outside React; keep UI details inside it

React's component, hook, context, and store models work well for UI state. It becomes less clear when one component also owns the whole application model. A stable operation can be called from the UI, a test, a REPL, or an agent.

setOrder({ ...order, status: "submitted" })

(def orders
  (atom {"order-42" {:status :pending}}))

(defn submit-order! [order-id]
  (swap! orders assoc-in [order-id :status] :submitted))

(submit-order! "order-42")

⚛React local detailHover state, open menus, input drafts, and animation state.this view

◉Hara application modelUsers, orders, documents, workflows, and live sessions.shared system

Ask: does this value still matter if this component disappears? If not, keep it in the component. If it does, give it a place in the application model.

Give shared state a clear address

Hara can divide an application into named spaces, instead of growing one global store of unrelated values.

Application node

model/sessionshared live state

model/ordersapplication model

page/dashboardview-specific state

document/report-42working document

Pages can display a model without owning it. Each bounded space has a clear address.

Use one vocabulary for local and remote work

Some work runs in the browser, some in a worker, and some on a server. Hara's request and event model lets the UI describe one application action while an adapter decides where the work runs.

UI action↓Named request
space · action · arguments↓Local handler
or transport↓Result

That lets a model begin locally and later move work into a Web Worker, service, or remote node without rewriting the UI around a new state model. Read the Substrate application architecture for the complete model.

Build an application that can answer questions

A live kernel exposes the current model rather than requiring developers to reconstruct it from logs and screenshots.

Current
stateNamed
operationChanged
value

Event or
requestPending
workTrace

Clear ownership → observable evidence → deliberate source change

This makes useful questions direct: what exists now; which operation changed it; which request is pending; which model owns a value; and which view depends on it. Inspectability is an architectural property, not merely a debugger feature added later.

Give AI agents runtime evidence

Source-only agents make a static guess about a running application. A bounded kernel interface gives an agent evidence from the actual model.

▤Read sourceUnderstand the durable definition.

◉InspectSee current runtime state.

λEvaluateTest one named operation.

◫ObserveCompare the result.

▣KeepChange source deliberately.

An agent can inspect a value, evaluate a revised function, call it, compare the before and after values, and save an accepted definition. Separate sessions and explicit capability boundaries can still limit access to files, network services, and browser APIs.

Start with one difficult part

Do not rewrite an entire application. Start with one model that is difficult to inspect: a document, workflow, browser game, dashboard, simulation, rules engine, collaborative editor, or AI-assisted feature. Give its state and operations names, connect it to the existing UI, then test the same model from the UI, REPL, and a separate agent or test session.

Hara is a good fit when that makes the important questions easier to answer. React still renders the application; Hara gives developers and agents a live model they can inspect, test, and change.