can i build a tui/cli interface with perryts?

[ralyodio]

all see good graphical UI support but not shell/cli support

[proggeramlug]

Short answer: CLI yes, TUI partial.

What works today for CLIs

• process.argv / process.env — process.argv[2..] is the user args (mimics Node).
• commander is implemented natively in perry-stdlib (Official commander docs example compiles successfully, but the generated binary ignores CLI arguments at runtime #187) — subcommands, options, --help / --version, .action() callbacks all fire. Just import { Command } from "commander" like in Node.
• fs, path, os, crypto, fetch, dotenv, nanoid, uuid, zlib, sqlite, plus the full string / array / JSON surface — everything you need for a real CLI tool.
• console.log writes raw bytes, so ANSI escape codes work — colors, cursor moves, clearing the screen, progress bars, etc. all render correctly. A chalk-style helper is ~10 lines, or just inline the escapes.
• process.stdout.write works for unbuffered output.

Compiled output is a single-file native executable (no Node runtime, no node_modules to ship) — perry mycli.ts -o mycli gives you a ~1 MB standalone binary, which is actually a really nice fit for CLIs.

What does not work yet for full TUIs

(blessed / ink / inquirer-style full-screen interactive UIs)

• No readline module (no line-buffered stdin reader).
• No tty.setRawMode / per-keypress input — process.stdin is a stub today.
• No tty.isatty, no process.stdout.columns/rows.
• No bundled TUI framework.

So: writing a git-style or npm-style CLI with subcommands, flags, file I/O, and colorful output? Fully supported and one of Perry's better-fit use cases. Writing a full-screen interactive TUI like htop or lazygit? Not yet — raw-mode stdin + readline are the gap.

Filed #347 to track the TUI primitives. If you have a specific TUI library or shape in mind, drop it on that issue and it can get prioritized.

[ralyodio]

need a good solid ncurses library i am using react-blessed now but its old and outdated and flaky

[proggeramlug]

Totally hear you on react-blessed — it's been in maintenance mode for years and the upstream blessed itself hasn't had a real release since 2017.

The path I'd rather take than building Perry-native ncurses is to make ink work as a perry.compilePackages target. Ink is the modern React-based successor to blessed, ships releases monthly, and is what most new TS TUIs in 2025 are built on (gh copilot, claude-code, etc.). That way Perry provides the runtime primitives (#347 — raw stdin / readline / tty.setRawMode / columns+rows) and ink stays the library, instead of us reinventing a TUI framework that immediately needs its own maintainer.

Filed #348 to track the ink-as-compilePackages work. The hard parts will be (a) yoga-layout (flexbox engine — native vs JS port), (b) wiring upstream react + react-reconciler for ink's renderer (Perry's existing perry-react is a different beast — it compiles JSX to native AppKit/UIKit widgets, not DOM-style React), and (c) shaking out whatever the dep tree (chalk / cli-cursor / string-width / etc.) trips over.

Order of operations: #347 lands first (ink can't render keystrokes until raw-mode stdin works), then #348 makes ink actually compile.

If you're already on react-blessed today, the migration to ink is mostly mechanical (both are React-renders-to-terminal); might be worth porting your app to ink under Node first while #347 + #348 are in flight, so when Perry support lands you just swap node for perry compile.

[ralyodio]

ink was pretty bad from my perspective that's why i switched to react-blessed.

[proggeramlug]

Fair — and the complaints are real, not just personal taste. The big one is flicker: stock ink does a full-tree traversal + complete buffer redraw on every state change, with no cell-level dirty tracking or double buffering. log-update.ts issues \e[2K\e[1A per line and rewrites everything, so on anything bigger than a static-ish UI you see the redraw. ink#359 ("long views flicker badly") has been open for years and is fundamentally architectural. It got bad enough that Anthropic rewrote the renderer from scratch for Claude Code v2.0.10 (Oct 2025) — kept React + Yoga + ANSI as the shell, but replaced the critical path with packed typed arrays, pool-based string interning, and double buffering. Their writeup basically says "started with Ink, then forked it beyond recognition." Add no React 19 support yet (ink#688) and a heavy dep tree, and yeah — I'm walking back the "ink is the obvious target" framing.

New plan, two tracks in parallel:

Track A — runtime primitives (#347). Raw-mode stdin, readline, tty.isatty, process.stdout.columns/rows, SIGWINCH. This unblocks everything — ink (#348), react-blessed, inquirer, Listr2, whatever comes next — as perry.compilePackages targets. Perry stays the runtime, the TUI library stays the library, the user picks. No favoritism.

Track B — perry/tui, a first-party native TUI engine (#358, just filed). Same architectural pattern as perry/ui does for native GUI: Rust-side renderer in a new perry-tui crate (Taffy for flexbox, packed cell grid, double-buffered, cell-level dirty tracking), with a thin declarative TS surface exposed as a built-in module. Designed from day one not to have ink's flicker problem — explicit anti-goal in the acceptance criteria is "streaming-log viewer appending 1000 lines/sec shows no visible flicker." For users who want zero-flicker out of the box and don't care which JS lib is under the hood, this becomes the recommended path; for users with an existing ink/react-blessed app, Track A means it just works.

Both tracks need #347 to land first regardless.

@ralyodio — what specifically pushed you off ink? Flicker, dep size, the React mental model, or something else? Useful signal for what perry/tui's API should and shouldn't look like.

[ralyodio]

It was the full re rendering

We need something solid for js like htop I think that uses python python had good tui libraries maybe we can steal from them lol