Other TUI Libraries: JVM, Kotlin, Node.js & Swift

Every library here takes over the terminal for a full-screen interface (raw mode, and for most of them the alternate screen), so every pitfall of that mode applies: the program must restore the terminal on every exit path, must not be started when standard input or output is not a terminal, and should be reachable only behind an explicit subcommand such as shelf tui. A library that does this for you (Ink does, as shown below) still leaves signals and uncaught exceptions to the program.

Lanterna is a pure-Java library for text-mode interfaces. Its README describes it as a library "for creating semi-graphical user interfaces in a text-only environment" with no native dependencies, in the style of curses. It is organised in three layers, each usable on its own:

DefaultTerminalFactory chooses the implementation at run time. On a machine with a graphical environment it opens a bundled Swing-based terminal emulator window instead of using standard output, which lets a developer run the program from an IDE (whose console is not a real terminal) and deploy the same code to a headless server. This is Lanterna’s answer to the "no TTY under the IDE" problem that Mosaic users meet (see below).

Installing it is one dependency; the README’s Maven snippet still shows 3.1.2, while Maven Central lists 3.1.5 as the latest stable release and 3.2.0-alpha1 as a pre-release.

Source: Lanterna — README

TamboUI is a newer Java library for terminal user interfaces. The project README says it brings the paradigms of Rust’s Ratatui and Go’s Bubble Tea to Java, and the project site describes it as inspired by Ratatui and Textual; the two pages do not agree, and both are quoted rather than reconciled. It is declared experimental by its README, which also says "APIs may/will change", so pin an exact version and read the release notes at every upgrade, as is advised for Ratatui on Ratatui: Testing & Ecosystem.

The modules published on Maven Central under the group dev.tamboui at 0.6.0 map onto the layers of Ratatui:

Maven Central also lists artifacts for images, Markdown, effects and annotation processing, which the pages read do not describe; they are not covered here. The README states that the library requires Java 8 or later with Java 17 or later "highly recommended". The site says the same and adds that its quick-start example uses a Java 25 feature (an instance main method, so the source file has no class declaration). Native executables built with GraalVM are mentioned on the site; no figures for size or startup time are given there.

The README says TamboUI is "currently only available as snapshot builds", but Maven Central lists releases from 0.1.0 to 0.6.0, the latest published on 2026-10-12. The README text is therefore out of date; the Maven Central listing is what this page relies on.

Mosaic, by Jake Wharton, applies the Jetpack Compose compiler and runtime to the terminal. The README describes it as "An experimental tool" and says it is inspired by Ink: composable functions describe the output, and when the state they read changes, the affected part of the screen is redrawn. The model is the one of Compose UI, with remember, mutableStateOf, LaunchedEffect and coroutines for background work; unlike Ink it needs no JavaScript runtime and, as the Maven Central listing shows, it is published for the JVM and JavaScript and for native Linux, macOS and Windows (mingwx64) targets, so a Kotlin/Native executable is possible (see the JVM page for Kotlin/Native executables).

Setup is a Gradle module with the Kotlin Compose compiler plugin applied and one dependency:

The Kotlin version shown is an example, not a statement of what Mosaic 0.18.0 requires; the README says only to apply the JetBrains Kotlin Compose plugin to every module that calls runMosaic or defines a @Composable function.

Source: Mosaic — README

This is the shape of the README’s counter example (runMosaic, a remembered mutableIntStateOf, a LaunchedEffect with delay) with the text changed to the Bookshelf; the imports, which the README does not list in full, should be checked against the version installed. The README notes that getValue and setValue may need to be imported by hand for the by delegate. The README documents Text and the counter and a keyboard-driven robot sample; it does not describe an input API, a layout set (rows, columns, borders) or testing support in the text read for this page, so a shelf tui list-and-details screen is not shown.

Two pitfalls follow from how Mosaic is run. First, the README warns against running a Mosaic program through Gradle or an IDE, because neither provides a terminal and the output breaks; build the application and run the binary in a real terminal emulator. Second, because there is no documented input API in the pages read, treat a Mosaic program as an output renderer (progress and status views, for which it is an attractive alternative to hand-written escape sequences) until you have verified the keyboard support of the version you use.

Ink is "React for CLIs": components are rendered to the terminal and laid out with flexbox through Yoga. It is the most widely used library on this page and the one the AI section already introduces on Node.js CLI Frameworks. This page assumes that introduction and adds what changes in Ink 8.

blessed describes itself as "a curses-like library with a high level terminal interface API for node.js". It is written entirely in JavaScript, reads terminfo and termcap itself rather than linking ncurses, and offers a DOM-like widget API: boxes, lists, forms, inputs, prompts, progress bars, tables, an embedded terminal and image display, with mouse and keyboard events that bubble through the element tree. It was the Node.js choice for full-screen interfaces for years, and dashboards such as terminal system monitors were built on it.

Its maintenance status is the reason for including it here. The npm registry lists 0.1.81 as the latest version, published in 2015; the repository, which is not archived, was last pushed to in March 2024. The fork neo-blessed has latest at 0.2.0, published in 2018. Neither README says that the project is abandoned, and the pages read for this page do not mention neo-blessed at all, so this is a finding from the registry and the repository’s activity, not a statement from the maintainers. The practical advice is to avoid choosing blessed or neo-blessed for new work, to keep an existing blessed program pinned and tested on the terminals you ship to, and to look at Ink (or at a binary built with a language from the other TUI pages) for a replacement. The blessed documentation does not state which operating systems are supported.

SwiftTUI brings the SwiftUI programming model to the terminal: a View with a body, stacks, text, buttons and text fields, @State and @Binding, and Application(rootView:).start(). Focus moves with the arrow keys. The README lists macOS and Linux, Swift 5.6 in its badge, and the MIT licence. The GitHub repository shows 116 commits, and the last commit is from July 2024; the latest tag is 0.1.0. That makes it suitable for a prototype or for learning, and a risk for a shipping product: check that it still builds with the current Swift toolchain (6.4.1 at the time of writing) before depending on it. The first look and the package manifest are on Swift & .NET CLI Frameworks; the Swift build side is on Command-Line Tools in Swift.

Source: SwiftTUI — README

This snippet was not compiled for this page. It uses the constructs the README lists as working (stacks, Text, Button, @State, Application(rootView:).start()); the modifiers bold(), border() and padding(_:) and the alignment: argument are taken from the SwiftUI vocabulary SwiftTUI mirrors, and the README text read does not list them, so verify them against the checked-out sources. The smaller view on the AI-section page, VStack, Text and Button inside Application(rootView:).start(), is the one that was compiled against Swift 6.4. Windows is not listed among the platforms. For a Swift tool that must be a real product today, a sensible route is to keep the interface in another library or to drive a terminal library through a C interface.

The same decision as a flow, followed by the rule that applies to all of them:

Whatever the library, start the interface only behind its own subcommand, keep every operation available without it, refuse to run it when standard input or output is not a terminal, and test it through a pseudo-terminal on every operating system you ship.