When an Edit Can Keep a Program Running

The Difference Is the State You Keep

A preview can react to an edit by throwing away the page and loading it again. That shows new code, but it may also reset the canvas, counters, text input and callbacks. The useful question is whether an edit can reach the running program while preserving the state you are trying to inspect. The original Light Table already had browser-connected evaluation and inline feedback; the upstream Electron guide describes webviews and remote debugging for browser evaluation. A manual isolated calculation alone does not recover that connected workflow.

The restored Light Table live view now supports that distinction for a defined set of changes. Named top-level classic JavaScript function bodies and supported primitive constants can update without rerunning initialization. Compatible CSS and markup changes can retain matched nodes and typed input. The recorded demo keeps its canvas and pointer interaction while speed, color and count change. This is later evidence than the manual 43 calculation screenshot.

Use Wrappers and Live Values

The reference installation used the debugger's script-replacement mechanism. A compatibility probe in the current Chromium runtime rejected that operation for the tested project script. Copying the old implementation would not restore this behavior.

The new implementation uses stable function wrappers and live constant cells, plus stylesheet changes and matched DOM updates. Existing callbacks keep a stable reference while the supported function body changes behind it. A supported constant read inside a function or callback can use its updated value. That avoids treating every source edit as a new program start.

The eligibility rule is deliberately narrower than “all JavaScript.” A constant used during initialization may already have affected state that cannot be reconstructed from its new text. Module bindings, arbitrary closures and initialization effects need more than replacing a function body.

Show When a Restart Is Required

Updates arrive after the live view's 350 ms edit debounce. Hot history is bounded to 128 updates and 32 MiB before a restart. Pause, Resume and Stop remain explicit menu actions. A live session has a 15-minute lifetime before an explicit Resume. These boundaries keep the behavior understandable when an edit falls outside the supported transformation.

Keep Observation Attached to the Right Code

The running page, the editor buffer and the last saved file can be different versions. Watches and source errors therefore carry captured identities. Unsaved edits remain unsaved; changed sources make observations stale. Stop and replacement checks prevent an older callback or pending reload from publishing a new-looking result after its run has ended.

For real development servers, Vite HTTP preview and HMR have separate tests. Captured-file live updates and a framework's own HMR are different routes. The existence of both does not mean arbitrary module state migration or every React project has been verified.

Test State, Not Just New Pixels

The completed live/language checkpoint includes seven transformation checks and ten native state checks, followed by the complete 37-entry regression, fresh Vite 33/33 and live demo 5/5. Native assertions cover object/callback/counter, renderer, canvas and typed-input identity. Source-linked error tests cover the exact patched text, and the final receipt binds 68 passing receipts to 246 frozen files.

That evidence supports the specified in-place changes. It does not establish full parity with the original editor's live-coding model. Arbitrary module state migration, browser ClojureScript, some language services and a complete end-to-end React workflow remain open. The practical gain is specific: supported edits can change a running example without erasing the state being studied.