FTXUI: a functional C++ terminal UI library, and where it stops being the right tool

The problem FTXUI solves for C++ programs

A C++ command line tool that grows past flags and subcommands eventually wants a list you can arrow through, a checkbox, a progress display that redraws in place. The traditional answer is ncurses, which gives you a cell grid and leaves layout, focus handling and event dispatch to you. FTXUI takes the opposite position: it treats the terminal as a rendering target for a tree of values, the way a browser treats a document. The README describes the library as a functional style inspired by React, and the example code reads that way, with elements composed by calling hbox, vbox and text rather than by writing escape sequences at cursor positions. The audience is narrow and specific: developers writing C++20 applications who want widgets and are willing to learn an API instead of a terminal protocol. If your program is not C++, nothing here helps you, because the library is distributed as C++ headers and sources, not as a service or a binding.

Three modules: screen, dom and component

The README splits FTXUI into three modules, and the split explains most of the design. The screen module is the low-level layer: colors, pixels, the terminal itself. The dom module defines a hierarchical set of Element values that manage layout and respond to terminal dimensions, declared in <ftxui/dom/elements.hpp>. The component module adds user interaction, widgets, events and a main loop. Elements compose spatially: horizontally with hbox, vertically with vbox, inside a grid with gridbox, or wrapped along one direction with flexbox, and the flex decorator makes an element absorb leftover space. The README's own example builds a row of three bordered text elements, gives the second and third the flex decorator, then stacks three gauges at 0.25, 0.50 and 0.75, each with a different color. Rendering is explicit: you create a Screen with Dimension::Full(), call Render(screen, document), then screen.Print(). That explicit render step is worth noting. Nothing redraws until you call it, so a component based application has to drive its own loop, which is what the component module's main loop exists to do. For most users the README recommends including everything at once through <ftxui/ftxui.hpp>.

Installing FTXUI and rendering a first document

The README lists many packaging routes, and it names CMake FetchContent as the preferred one. The README's example program is the shortest real use. It includes the aggregate header and renders a document:

#include <ftxui/ftxui.hpp>
using namespace ftxui;

int main() {
  auto document =
    vbox({
      hbox({
        text("one") | border,
        text("two") | border | flex,
        text("three") | border | flex,
      }),

      gauge(0.25) | color(Color::Red),
      gauge(0.50) | color(Color::White),
      gauge(0.75) | color(Color::Blue),
    });

  auto screen = Screen::Create(Dimension::Full());
  Render(screen, document);
  screen.Print();

  return 0;
}

Running it should print three bordered cells across the terminal, with the first sized to its text and the other two sharing the remaining width, followed by three gauges at a quarter, a half and three quarters, colored red, white and blue. The pipe syntax is operator overloading on Element, which is why the README calls the style functional rather than object oriented. Note that this program renders once and exits; it does not read input. For a menu or a form you need the component module, and the README points to the ftxui-starter repository as the starting point for that. Beyond CMake, the README points at vcpkg, Conan, Debian, Ubuntu, Arch Linux, OpenSUSE, XMake, Nix and conda-forge, and names the Bazel target @ftxui//:ftxui. It also documents an amalgamated single-header and single-source distribution starting from version 7.0.0, which avoids a package manager entirely.

What FTXUI does not do

The library has no dependencies, and that is a real constraint as much as a feature. There is no scripting layer, no configuration file format, no markup language. Every screen you build is C++ that you compile, so changing a label means a rebuild. Compare that with tools where the interface is described in a text file and interpreted at runtime, and the trade-off is clear: FTXUI buys type safety and speed at the cost of iteration speed. The README also does not document a rollback or compatibility policy, and it does not state which versions are supported. The release history shows v7.0.1, v7.0.2 and v7.0.3 within roughly a month of each other, which suggests patch releases arrive quickly, but the README does not say what those patches changed; the CHANGELOG.md file at the repository root is where that would be recorded. The README does not describe how the library behaves when the terminal is resized while a component loop is running, and it does not document fallback behaviour for terminals that do not support the escape sequences it emits. If your target environment is an old or unusual terminal emulator, that is unverified ground.

FTXUI vs ncurses: values against a cell grid

The comparison people search for is FTXUI against ncurses, and the difference is architectural rather than cosmetic. ncurses exposes a window and a grid of cells; you decide where each character goes, you manage the refresh cycle, and layout is arithmetic you write yourself. FTXUI exposes a tree of Element values that describe content and proportions, and the library resolves that tree against the current terminal size at render time. The README's hbox and vbox example is the clearest illustration: the second and third cells are marked flex and share whatever width remains, with no coordinate arithmetic in the program. The cost is that you give up direct control over individual cells. Drawing arbitrary graphics means going through the canvas element the README links to in its examples, not writing to a screen buffer. For a form, a menu, a log viewer or a dashboard, the FTXUI model removes a category of bugs around resize and focus. For a text editor, a terminal multiplexer, or anything where you need to reason about a character grid directly, ncurses or a similar cell-level library fits the problem better.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-20, so the project is being worked on. The three most recent releases are v7.0.3 on 2026-08-06, v7.0.2 on 2026-08-01 and v7.0.1 on 2026-07-14. That cadence matters for upgrade cost: three patch releases in under a month means you should expect to move versions, and the README does not promise API stability across them. The CHANGELOG.md at the repository root is the file to read before bumping a pinned version. On licensing, the repository carries an MIT licence, and the README links to it. MIT is permissive, so the obligations are the usual ones around retaining the copyright notice and licence text in distributions, but this is a description of the licence identifier, not legal advice, and the LICENSE file is the authoritative text. The README also notes C++20 module support, which is a build-system commitment: if your toolchain or your downstream consumers cannot consume modules, you are on the header path, and the README does not describe what that path costs in compile time.

Editorial conclusion

Adopt FTXUI if your program is already C++20 and needs keyboard and mouse driven widgets without pulling in a dependency tree; the CMake FetchContent path and the ftxui-starter repository are the shortest routes in. Do not adopt it if you want a markup language, a scripting layer, or a TUI framework you can drive from Python or Go. Before committing, verify which of the three modules you actually need, confirm that your toolchain accepts the C++20 module build if you intend to use it, and check the CHANGELOG for the API changes between v7.0.1, v7.0.2 and v7.0.3.

Frequently asked questions

Official sources

1. ArthurSonzogni/FTXUI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases