Core Concepts

Ansiq can be understood through four ideas:

1. runtime-first
2. retained tree
3. signal-first reactivity
4. terminal-native rendering

Everything else in the framework grows out of these.

1. Runtime-first

Many TUI libraries start with the question “how do we render widgets?” Ansiq starts with “who coordinates the whole terminal application?”

That means the runtime explicitly owns:

• app lifecycle
• focus
• input routing
• reactive flush scheduling
• subtree replacement
• partial relayout
• viewport and session behavior
• terminal patch emission

This is why Ansiq is a better fit for long-running interactive software than for one-off screen drawing.

2. Retained tree

Ansiq is not immediate mode.

It keeps a UI tree, updates only the parts that become dirty, and emits incremental patches from there.

This enables:

• dirty scope collection
• subtree replacement
• continuity state
• partial relayout

3. Signal-first reactivity

Ansiq uses:

• signal
• computed
• effect

The important part is not the names. The important part is the division of responsibility:

• reactivity decides what became dirty
• the runtime decides how to update the terminal

4. Terminal-native rendering

Ansiq does not target the browser DOM. It renders into a framebuffer, computes diffs, and emits terminal patches.

That is why viewport, scrollback, and terminal session behavior are part of the architecture instead of being incidental details.

The main pipeline

The runtime pipeline currently looks like this:

signals change
-> dirty scopes
-> subtree rerender
-> partial relayout
-> invalidated regions
-> framebuffer diff
-> terminal patch emission

Two boundaries you should keep in mind

Reactive graph vs UI tree

The reactive graph and the UI tree are different structures. They should stay different.

If you want the full explanation rather than the short slogan, the Internals page Reactive Graph vs UI Tree unpacks the model in detail.

Widgets vs runtime

Ansiq wants low-level widgets to stay ergonomic without turning the runtime itself into an immediate-mode system.

And if your next question is “what does the runtime loop actually do over the lifetime of an app?”, the Internals page Runtime Loop goes deeper.

Next

The best follow-up path is:

1. Reactivity
2. Components and view!
3. If you want internals early, continue with Lifecycle and Runtime Loop