Prior art

Looms combines established patterns from event-sourced systems, reducer architectures, actors, and durable execution. These systems shaped the model and provide useful points of comparison.

Event sourcing and projections#

Event Sourcing records state changes as an append-only sequence of events. Replaying that sequence reconstructs state; folding it into other shapes produces projections. Looms uses one canonical event stream per run for thread state, debugging, and UI projections.

Flux and Redux#

Flux popularized unidirectional data flow in JavaScript applications. Redux made the reducer form familiar: current state plus an action produces next state. Looms applies a related reducer model to durable event streams. Its events are persisted facts, and thread reducers can return effect instructions for the runtime to execute.

Actors#

Actor systems isolate mutable state and process messages serially. Looms uses that shape at the hosting boundary: one actor cell owns each runId and writes its log. Cloudflare Durable Objects are the primary production host, but the same single-writer contract works with local Bun actors and custom hosts.

Durable execution#

Systems such as Temporal, Restate, and DBOS let application work survive process failure and long waits. Looms shares those goals. Its programming model centers on event streams, pure reducers, explicit effect instructions, and modules that contribute thread kinds and projections.

React#

React made declarative UI and state-derived views common in frontend code. Looms borrows that broad approach: application code describes transitions and projections while the runtime schedules work and recovery. The analogy stops there. A Looms thread is not a React component, and a Looms effect is not useEffect. @swirls/looms/react is an adapter for subscribing to run streams and projections.

See Concepts for Looms terminology, Events & effects for reducer semantics, and Waits & replay for recovery behavior.