Rat'⚡go

Empower ratatui widgets event handling easily, let's go into carnival of ratatui right now !!!

Table of contents

• Introduction
• Features
• Examples
• Manual
• Roadmap
• Note

Introduction

ratzgo is a composable, async-first, Elm‑like ratatui framework. Rather than offering a batteries‑included component library, it focuses on simplifying the composition of ratatui widgets and reducing the complexity of maintaining TUI logic.

Features

• Composable: Compose view units raztgo::core::Component however you like.
• Async-first: The application runs inside an async event loop.
• Elm-like: View-Message-Update architecture, implemented in Rust with async support.
• Controllable reactive: Control whether a component reacts to events via raztgo::core::Component::active.
• Message passing: Send message directly, or spawn background tasks that return message with UnsyncQueue.
• Custom event sources: Listen to multiple Streams simultaneously using SelectEventSource.
• Yield foreground: Hand back interactive control to the terminal with YieldFg.
• Debouncing: Drop stale Futures effortlessly with UnsyncDebounce.
• Logging: Publish logs to LogStream from anywhere.
• Z‑axis stacking: Use Stack container and MountPoint for floating layers, opening modals, popups, and toast anywhere in view logic.
• Scroll & fit: Scroll by fixed row/column count or screen percentage, with optional margins.

Examples

For a working example, you can refer to my jujutsu TUI.

Manual

TODO

Roadmap

Refer to github issue: ratzgo Roadmap

Note

You may have noticed that the word Unsync... appears several times throughout this article. This is because I chose compio as the async runtime. For client‑side applications, UI logic always runs on a single thread, and completion‑based async (e.g., io_uring) can initiate I/O operations at a lower cost than polling‑based async (e.g., epoll). I'm not meaning opposed to multi‑threaded parallelism – you are free to bring in your own thread pools and channels, and combine them with ratzgo async utilities to maximize task throughput.

Still, tokio is brilliant in the Rust world. The well-known reqwest crate, for instance, has a hard dependency on tokio. Tokio’s work‑stealing mechanism, designed for load balancing, also delivers higher task throughput than the thread-per-core model under moderate QPS. Tokio also natively supports an M:N model, making it easy to run asynchronous tasks on thread pools. All of this is undeniably tempting. But I haven’t figured out if or how to support both I/O models. Since the divergence between completion-based and polling-based async has profound implications for Rust’s async runtime modeling. Adding such support would inevitably bring significant challenges to ratzgo. For now, I’ll leave the answer to time.