Comparison: robit vs pi-mono

Philosophy: Rust + WebAssembly Only

Unlike pi-mono’s TypeScript-based approach, robit is committed to Rust and WebAssembly exclusively. No TypeScript frontend frameworks. If we ever need richer web capabilities beyond terminal UI, we’ll use Leptos (Rust) or enhance the WASM build—not JavaScript.

This decision reflects:

Type safety: Rust’s compile-time guarantees across all platforms
Performance: Zero-cost abstractions, no JS runtime overhead
Consistency: Single language, single toolchain
WASM-first: Browser deployment via Rust-to-WASM, not JS bundlers

pi-mono Overview

pi-mono is Mario Zechner’s AI agent toolkit (11k+ GitHub stars). It powers the Pi coding agent and includes:

pi-ai: Unified LLM API (OpenAI, Anthropic, Google, etc.)
pi-agent-core: Agent runtime with tool calling
pi-tui: Custom terminal UI library with differential rendering
pi-web-ui: Web UI components (Lit-based web components)
pi-coding-agent: Main CLI tool (uses pi-tui)
pi-mom: Slack bot that wraps the coding agent

Architecture Comparison

Package Structure

pi-mono:

packages/
├── ai/                    # LLM abstraction
├── agent/                # Agent runtime
├── tui/                  # Terminal UI library (custom)
├── coding-agent/         # CLI (uses pi-tui)
├── web-ui/               # Web components (separate)
└── mom/                  # Slack bot

robit (proposed):

crates/
├── robit-core/         # Shared business logic
├── robit-tui/          # Terminal app (ratatui)
├── robit-web/          # Web app (ratzilla - same UI code!)
└── robit-cli/          # CLI interface

Key Difference: UI Strategy

pi-mono: Separate UI Implementations

pi-tui (terminal)     pi-web-ui (browser)
     │                       │
     └──────────┬────────────┘
                │
         pi-agent-core
                │
              pi-ai

pi-tui: Custom TUI library (chalk, marked, differential rendering)
pi-web-ui: Lit web components (document previews, chat UI)
Different UI code for each platform
Optimized for each platform’s strengths

robit: Shared UI Code

ratatui widgets ──┬── crossterm (terminal)
                  └── ratzilla (web DOM)
                          │
                    robit-core

Same ratatui widgets used everywhere
Different backends (crossterm vs ratzilla)
Single UI codebase
Trade-offs in platform optimization

Technical Deep Dive

pi-tui: Custom Terminal Library

pi-mono built their own TUI library instead of using blessed, react-blessed, or ink:

Features:

Differential rendering: Only updates changed lines
Component interface: React-like component system
Viewport management: Scrollback handling
ANSI safety: Proper escape sequence handling
Overlay system: Modal dialogs, popups
Custom editor: Built-in text input with syntax highlighting

Dependencies:

chalk - Terminal styling
marked - Markdown rendering
get-east-asian-width - Character width calculation
mime-types - MIME detection

Why custom?

Full control over rendering performance
Optimized for streaming LLM output
Differential updates reduce flicker
No React overhead (Ink uses React)

pi-web-ui: Web Components

Separate package using Lit (web components):

Features:

Chat interface components
Document previews (docx, pdf, xlsx)
Local LLM integration (LM Studio, Ollama)
Peer dependency: mini-lit or lit

Notable: Uses pi-tui for “shared rendering logic” (some code reuse)

Trade-off Analysis

pi-mono Approach: Separate UIs

Pros:

Platform-optimized: Terminal UI optimized for terminal, web for web
Full feature set: Can use web-specific features (drag-drop, file previews)
No WASM complexity: Web UI is regular JavaScript
Better performance: Native web components vs WASM overhead

Cons:

Code duplication: Two UI implementations
Maintenance burden: Changes need to be made twice
Inconsistency risk: UI may drift between platforms
More packages: Separate teams could diverge

robit Approach: Shared UI (ratatui + ratzilla)

Pros:

Single codebase: One UI implementation
Consistency guaranteed: Same behavior everywhere
Faster iteration: Changes apply to all platforms
Unique aesthetic: Terminal look in browser is distinctive

Cons:

Terminal aesthetic in web: May feel odd on mobile
WASM complexity: Build tooling, debugging
Limited web features: Harder to add drag-drop, rich previews
Performance overhead: WASM vs native JS

Lessons from pi-mono

1. Differential Rendering Matters

pi-tui’s differential rendering is critical for smooth streaming output:

// Only re-render changed lines
for (let i = firstChanged; i <= lastChanged; i++) {
    if (previousLines[i] !== newLines[i]) {
        updateLine(i, newLines[i]);
    }
}

ratatui does this too - it’s a core feature. Good validation.

2. Separate Packages Enable Different Use Cases

pi-mono’s pi-mom (Slack bot) wraps pi-coding-agent instead of using core directly:

pi-mom ──→ pi-coding-agent ──→ pi-agent-core

This allows the Slack bot to:

Reuse all interactive features
Share state management
Not reimplement agent logic

Lesson: Consider wrapper patterns for different interfaces.

3. Web UI Can Be Richer

pi-web-ui includes:

Document previews (PDF, Word, Excel)
Drag-and-drop file upload
Rich text editing

These are hard in WASM TUI but easy in web components.

Lesson: If we need rich web features, we might need a separate web UI eventually.

4. Extension System Enables Ecosystem

pi-coding-agent has a sophisticated extension system:

TypeScript runtime compilation
Event hooks
Tool/command registration
Custom providers

Lesson: Plan for extensibility from the start.

5. Custom TUI Libraries Are Viable

pi-mono built pi-tui instead of using existing libraries. Reasons:

Performance control
Streaming optimization
Specific feature needs

Lesson: Don’t be afraid to build custom if needed, but ratatui is battle-tested.

Strategic Implications

When pi-mono’s Approach Wins

Rich web experience needed: File previews, drag-drop, WYSIWYG
Different teams/platforms: Web team and terminal team
Performance critical: WASM overhead unacceptable
Web-first product: Terminal is secondary

When robit’s Approach Wins

Terminal is primary: Web is convenience feature
Small team: Can’t maintain two UIs
Consistency valued: Same experience everywhere
Unique aesthetic: Terminal-in-browser is brand differentiator
Offline-first: WASM works without server

Hybrid Possibilities

Could we combine both approaches?

Option 1: Terminal-First Hybrid

┌─────────────────────────────────────────┐
│           Native Terminal               │
│         (ratatui + crossterm)           │
│                                         │
│   Full TUI experience                   │
│   Vim bindings, keyboard-centric        │
└─────────────────────────────────────────┘
                    │
         ┌──────────┼──────────┐
         │          │          │
         ▼          ▼          ▼
   ┌──────────┐ ┌────────┐ ┌──────────┐
   │  WASM    │ │  PWA   │ │  Rich    │
   │  TUI     │ │  Shell │ │  Web UI  │
   │          │ │        │ │(optional)│
   │Terminal  │ │ Mobile │ │ React/   │
   │aesthetic │ │ basic  │ │  Vue     │
   └──────────┘ └────────┘ └──────────┘

Primary: Native terminal (ratatui)
Convenience: WASM TUI (ratzilla)
Mobile: PWA wrapper
Rich features: Optional separate web UI (if needed)

Option 2: Platform-Specific UIs

Start with shared UI, split when needed:

Phase 1: Shared UI (ratatui + ratzilla)
   │
   ├──> Phase 2a: Rich web features needed?
   │      └──> Build separate robit-web-rich
   │
   └──> Phase 2b: Terminal-only sufficient?
          └──> Keep shared UI

Recommendations

For robit

Start with shared UI (ratatui + ratzilla)
- Faster to MVP
- Consistency is a feature
- Terminal aesthetic is distinctive
Plan escape hatches
- Keep core UI logic separate from rendering
- If web needs rich features, we can split later
- Conditional compilation for platform features
Learn from pi-tui
- Differential rendering (ratatui has this ✓)
- Component-based architecture (ratatui has this ✓)
- ANSI safety (crossterm handles this ✓)
Evaluate at Phase 3
- If web needs file previews → consider separate web UI
- If terminal remains primary → stick with shared UI

Key Questions to Answer

Is terminal aesthetic acceptable for web users?
- pi-mono users: yes (web UI is different)
- Our users: TBD (shared UI means terminal in browser)
Do we need rich web features?
- File drag-drop?
- PDF previews?
- Collaborative editing?
Is WASM overhead acceptable?
- Initial download size
- Runtime performance
- Mobile battery impact

Conclusion

pi-mono and robit represent fundamentally different philosophies:

Aspect	pi-mono	robit
Language	TypeScript (Node.js)	Rust
Web approach	Lit web components	WASM (Rust)
UI strategy	Platform-specific	Shared UI code
Rich web path	More TS/JS components	Leptos (Rust) or enhanced WASM
Ecosystem	npm, webpack, etc.	Cargo, trunk, wasm-bindgen

robit Philosophy

Rust + WebAssembly exclusively. No exceptions.

If we ever need richer web capabilities:

First: Enhance the ratzilla WASM build (add custom components)
Second: Introduce Leptos for a separate rich web UI (still Rust, still WASM)
Never: TypeScript, React, Vue, or JavaScript frontend frameworks

This isn’t about being dogmatic—it’s about:

Type safety across the stack
Single toolchain and language
WASM as first-class deployment target
Avoiding JS ecosystem complexity

Validation

The ratatui + ratzilla approach is correct for our goals:

Terminal-first workflow ✓
Web deployment without JS frameworks ✓
Rust everywhere ✓
Path to Leptos if needed ✓

pi-mono’s TypeScript approach works for them. Our Rust approach works for us. Both are valid; we’ve chosen ours.

Keyboard shortcuts

Robit