Compare

This page puts FrankenTUI next to the three most common Rust TUI options — Ratatui , the archived tui-rs , and raw crossterm  — and explains where they agree, where they diverge, and when each is the right choice.

This is for readers who already know one of those stacks and want to know whether switching is worth the friction. If you don’t know any of them, read what is FrankenTUI? first.

The summary: FrankenTUI is not a drop-in Ratatui replacement. It is a different shape of thing — a kernel with a stricter contract — and picking between them is mostly a question of whether you want the kernel guarantees badly enough to accept a moving API.

Motivation

Every choice of TUI substrate locks in a different contract. Ratatui leaves terminal lifecycle to the application; FrankenTUI owns it. Crossterm is a transport layer; FrankenTUI is a runtime on top of crossterm that enforces a rendering model. Getting this choice wrong shows up late, usually as “terminal corrupted after crash” or “my inline UI flickers under load.”

Mental model

FrankenTUI and Ratatui both sit on crossterm. The difference is what they own: FrankenTUI owns the terminal lifecycle, the runtime loop, the effect system, and the evidence ledger. Ratatui owns a Terminal and a buffer diff; the loop is yours.

Feature matrix

Where each fits best

FrankenTUI

Pick FrankenTUI when you want the kernel guarantees listed above and are willing to accept a moving API. Concrete situations where that trade is worth it:

• An inline dashboard attached to a long-running CLI (build tools, package managers, cluster operators) where logs must continue to scroll.
• A rendering harness that needs byte-identical output for snapshot testing or replay debugging.
• A UI with resizable pane workspaces and full undo/redo/replay semantics.
• A codebase that needs to ship both terminal and web from a single Rust source tree.
• Work that benefits from principled statistical decisions (capability detection, resize coalescing, frame-budget gating) being observable via an evidence ledger rather than hidden in thresholds.

Ratatui

Pick Ratatui when you want a mature, stable, community-driven framework with a broad example set. Ratatui’s contract is lighter: you own the loop and the terminal lifecycle, which means less magic and fewer surprises when you want to do something unusual. If you’re building a one-off TUI and the inline-mode strategies aren’t central to your design, Ratatui will get you there with less ceremony.

tui-rs

Don’t pick tui-rs. It’s archived; Ratatui is the maintained fork. The row exists here only so readers migrating away from tui-rs can see how the options line up.

Raw crossterm

Pick crossterm directly when you are building a library (not an app) that needs to emit ANSI without committing to a runtime. Anything larger than a progress spinner or a prompt, and you should wrap crossterm in either Ratatui or FrankenTUI.

Honest trade-offs

Other places FrankenTUI is demonstrably weaker than Ratatui:

• Community size. Ratatui has a much larger ecosystem of widgets, examples, and third-party integrations.
• Book-length docs. Ratatui ships a structured book; FrankenTUI’s docs are what you’re reading.
• Windows support. FrankenTUI targets Linux and macOS first; Windows is tracked via docs/WINDOWS.md with a deferred native-backend strategy.

Places FrankenTUI is demonstrably stronger:

• Terminal lifecycle guarantees. TerminalSession restores state on drop, including panic. Ratatui leaves this to the application.
• Inline-mode first-class. Three inline strategies selected by capability, not ad-hoc flags.
• Intelligence layer. Resize coalescing, diff strategy selection, and frame-budget gating are all driven by Bayesian posteriors logged as evidence, not tunable thresholds.
• Pane workspaces. The ftui-layout::pane subsystem has no equivalent in Ratatui or crossterm.

Pitfalls

Where next