On this pageOverview
Architecture
In most TypeScript UI frameworks, each component manages its own state and effects. In Foldkit, there’s a single state tree; every change flows in one direction through the same loop.
This pattern is called The Elm Architecture. You don’t need to know Elm — Foldkit adapts it for TypeScript and Effect.
Every Foldkit app runs the same loop. A Message arrives — the user clicked a button, a timer fired, an HTTP response came back. The update function receives the current Model and the Message and returns a new Model along with any Commands to execute. The view function renders the new Model as HTML. When the user interacts with the view, it produces another Message, and the loop continues.
Commands are descriptions of side effects — HTTP requests, timers, browser API calls. The Foldkit runtime executes them and sends their results back as new Messages, feeding them into the same loop.
That’s it. Message → update → Model + Commands → view → Message. Every state transition in your app flows through this single loop. There’s no action-at-a-distance, no hidden state mutation, no effect that runs outside the cycle. If you want to know how the app got into its current state, you follow the Messages.
Think of a Foldkit app like a restaurant. The waiter keeps a notebook — a running picture of everything happening right now. Table 3 ordered the salmon. Table 5 is waiting for dessert. When something happens — a customer flags the waiter, the kitchen rings the bell — the waiter hears about it, updates their notebook, and maybe writes a slip for the kitchen. The waiter doesn’t cook the salmon — they hand the slip to the kitchen, and the kitchen reports back when it’s done.
Messages work the same way. "Table 3 asked for the check" is a fact given to the waiter, not an instruction. The waiter decides what to do — maybe bring the check immediately, maybe offer dessert first. The message stays the same either way.
The restaurant analogy
This analogy maps to every concept you'll encounter in Core Concepts. The table below is a reference you can come back to as you read.
| Your App | The Restaurant |
|---|---|
| Model | The waiter's notebook — the current state of everything |
| Message | Something that happens: "table 3 asked for the check" |
| update | The waiter — hears what happened, updates the notebook, maybe writes a slip |
| view | What the customers actually see — plates on the table, the check arriving |
| Command | A slip for the kitchen: "prepare the salmon" |
| Subscription | A standing order: "keep the coffee coming for table 5" |
| Runtime | The kitchen — does the work, reports back when done |
That's the architecture in the abstract. The next page shows a complete counter application — and you'll see each of these pieces in the code.