SuperLightTUI

Superfast to write. Superlight to run.

Docs Index · Quick Start · Widget Guide · Patterns Guide · Examples Guide · Backends Guide · Architecture Guide

English · 中文 · Español · 日本語 · 한국어

SuperLightTUI is an immediate-mode TUI library for Rust with a deliberately small public grammar. You write one closure, SLT calls it every frame, and the library handles layout, focus, diffing, and rendering.

It is designed for fast product iteration, approachable Rust syntax, and serious backend discipline. That makes it work equally well for humans prototyping a tool and for coding agents generating UI from docs.

Showcase

Quick Start

cargo add superlighttui

fn main() -> std::io::Result<()> {
    slt::run(|ui: &mut slt::Context| {
        ui.text("hello, world");
    })
}

5 lines. No App trait. No Model/Update/View. No manual event loop. Ctrl+C just works.

60-Second Grammar

There are four ideas most apps start with:

1. State lives in normal Rust variables or structs.
2. Layout is mostly row(), col(), and container().
3. Styling is method chaining.
4. Interactive widgets usually return Response.

ui.bordered(Border::Rounded).title("Status").p(1).gap(1).col(|ui| {
    ui.text("SLT").bold().fg(Color::Cyan);
    ui.row(|ui| {
        ui.text("mode:");
        ui.text("ready").fg(Color::Green);
        ui.spacer();
        if ui.button("Quit").clicked {
            ui.quit();
        }
    });
});

That is the core mental model. Everything else is depth, not a second framework.

A Real App

use slt::{Border, Color, Context, KeyCode};

fn main() -> std::io::Result<()> {
    let mut count: i32 = 0;

    slt::run(|ui: &mut Context| {
        if ui.key('q') {
            ui.quit();
        }
        if ui.key('k') || ui.key_code(KeyCode::Up) {
            count += 1;
        }
        if ui.key('j') || ui.key_code(KeyCode::Down) {
            count -= 1;
        }

        ui.bordered(Border::Rounded).title("Counter").p(1).gap(1).col(|ui| {
            ui.text("Counter").bold().fg(Color::Cyan);
            ui.row(|ui| {
                ui.text("Count:");
                let color = if count >= 0 { Color::Green } else { Color::Red };
                ui.text(format!("{count}")).bold().fg(color);
            });
            ui.text("k +1 / j -1 / q quit").dim();
        });
    })
}

Why SLT

• Small public grammar. Most screens start with normal Rust state, row() / col() / container(), method chaining, and Response.
• Less framework ceremony. Many apps do not need an app trait, retained tree, or message enum just to get moving.
• Batteries included, backend still serious. Common widgets auto-wire focus, hover, click, and scroll behavior, while the runtime keeps a conservative low-level path through Backend, AppState, and frame().
• Conservative internals. SLT keeps the public surface small, but the internals stay deliberately boring: shared frame kernel, explicit backend contract coverage, zero unsafe, feature-gated runtime paths, and validation across all-features, no-default-features, WASM, clippy, examples, cargo-hack, semver, and deny checks.

For Rust users, that usually means less setup than retained-mode TUI frameworks. For AI-assisted workflows, it means the public grammar is easy to infer from docs and examples.

SLT fits best when you want to build terminal apps quickly without giving up Rust type safety or backend escape hatches. If you want a retained component tree or a GUI-first toolkit, another library may be a better fit.

How It Renders

SLT's rendering pipeline is why the grammar stays small. Your code only touches the first stage — the engine handles the rest.

graph LR
    subgraph your_code ["Your Code"]
        A["Closure"]
    end
    subgraph engine ["SLT Engine"]
        B[Commands] --> C[Build Tree] --> D[Flexbox] --> E[Collect] --> F[Render] --> G["Diff + Flush"]
    end
    A -->|"records intent"| B
    G -.->|"prev-frame feedback"| A

Every ui.*() call records a command to a flat list — no tree construction, no layout math. The engine replays those commands through a pipeline: build a layout tree, compute flexbox, collect hit areas and focus groups in a single DFS pass, render cells to a back buffer, then diff against the previous frame and flush only what changed.

This architecture is what makes the simple grammar possible:

• No ceremony. Immediate-mode means no App trait, no Model/Message/Update/View. Your closure is the entire UI. State is normal Rust variables. Control flow is if/for.
• Invisible layout. ui.col(|ui| { ... }) records an "open column" command. The engine builds the tree and runs flexbox — you never see LayoutNode.
• Automatic performance. The double-buffer diffs cells between frames and only emits changed ANSI attributes. You redraw everything; the engine makes it fast. No manual dirty tracking.
• Auto-wired interaction. ui.button("Save") gives you hover, click, and focus for free. collect_all() gathers all interaction data in one DFS pass — replacing seven separate tree traversals.
• Synchronous feedback. Interaction uses the previous frame's layout positions (imperceptible at 60 FPS). No callbacks, no async layout queries — your code stays linear.

For the full eight-stage lifecycle, see Architecture Guide.

Common API Surface

// Text and layout
ui.text("Hello").bold().fg(Color::Cyan);
ui.row(|ui| {
    ui.text("left");
    ui.spacer();
    ui.text("right");
});

// Inputs and actions
ui.text_input(&mut name);
if ui.button("Save").clicked {}
ui.checkbox("Dark mode", &mut dark);

// Data and navigation
ui.tabs(&mut tabs);
ui.list(&mut items);
ui.table(&mut data);
ui.command_palette(&mut palette);

// Overlays and rich output
ui.toast(&mut toasts);
ui.modal(|ui| {
    ui.text("Confirm?").bold();
});
ui.markdown("# Hello **world**");

// Visualization
ui.chart(|c| {
    c.line(&data);
    c.grid(true);
}, 50, 16);
ui.sparkline(&values, 16);
ui.canvas(40, 10, |cv| {
    cv.circle(20, 20, 15);
});

For the categorized widget list, see Widget Guide. For composition advice, see Patterns Guide.

Learn The Library

Representative Examples

The full categorized index lives in Examples Guide.

Custom Widgets And Backends

• Implement Widget when you want reusable high-level building blocks.
• Implement Backend and drive frame() when you want a non-terminal target, external event loop, or embedded runtime.
• Use TestBackend for headless rendering checks and stable interaction tests.

The public grammar stays small even when you need the escape hatches.

Contributing

Read Contributing, then Design Principles and Architecture Guide. The release process expects format, check, clippy, tests, examples, and backend gates to stay green.

License

MIT