logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·31.10.26
← Back to news

Stop Making TUIs

Original article
sockpuppet.org|341 points|437 comments|by underdeserver|Aug 21, 2026

Stop Making TUIs

By Ward Meta | August 20, 2026

Our industry maintains a bizarre, almost sentimental attachment to the command line and terminal interfaces. Recently, I've been pushing my peers to abandon this habit and embrace the creation of native user interfaces.

After developing my first substantial macOS application a few months back, I've entered a phase of productivity where I'm building more native UI tools than I did in my entire previous career.

The Portfolio of Native Tools

One such creation is MDV.app. I consider it the premier Markdown viewer currently in existence—at least until a more serious competitor emerges. I won't bore you with a sales pitch for it, but I will admit that crafting high-quality UI is a grueling process. It is often:

  • Tedious and repetitive.
  • Exacting in its requirements.
  • Gated by a need for deep platform-specific conceptual knowledge.

1. The SageMath Frontend

After spending a year with Math Academy (progressing from Foundations I through Machine Learning—essentially teaching myself calculus), I built a native, calculator-style interface for SageMath, the gold standard for cryptographers.

This app provides three critical advantages:

  1. Automatic Rendering: It converts Sage output into LaTeX\LaTeXLATE​X (essential for multivariable calculus).
  2. Object Interaction: It uses point-and-click menus to expose methods for vectors and matrices, sparing me from typing trig_simplify repeatedly.
  3. Shorthand Input: A "mini-language" for rapid operations. For example, defining a matrix is as simple as: [1234]→input as [1,2;3,4]\begin{bmatrix} 1 & 2 \\ 3 & 4 \end{bmatrix} \rightarrow \text{input as } [1,2;3,4][13​24​]→input as [1,2;3,4]

2. The AI-Powered Music Player

I've also developed an AI-assisted music player that mirrors about 90% of the functionality found in Music.app.

"This is the personal computing equivalent of slaying a dragon."

The architecture is quite sophisticated:

  • Backend: A SQLite database with a clean, logical schema.
  • Agent: An embedded LLM agent capable of tool calls to analyze my library, recently played tracks, and upcoming queue.
  • Execution: Unlike other apps that use a Responses API, this drives claude -p internally.
  • Filesystem Hack: To help the agent "grovel" through data, I implemented a macOS virtual filesystem extension. This presents the SQLite database as a read-only mounted drive within the app's sandbox.

3. Miscellaneous Utilities

I've also built several smaller, highly specific tools:

  • Food Macro Tracker: A GPT-5 powered agent. I can give it a vague description—I ate a whole cake "tasting cake batter and cream cheese frosting (but no actual cake)"—and it estimates the caloric intake.
  • Home Temp Monitor: A menu-bar app for TP-Link sensors. (Note: These sensors likely grant the CCP access to my Apple TV). I didn't bother documenting the HTTP APIs; I just found the two sign-in paths for cloud and local pod access.
  • Universal Remote: A native Swift menu-bar app to control my Apple TV, Roku, and Denon receiver. This is a godsend for when I'm watching House Of Ninjas with my spouse and have my MacBook on my lap.

While the original logic for Apple TV control was written in Python libraries, I translated the concepts into Swift. As far as I'm concerned, if a logic exists in Python, it's effectively available in Swift, C#, or even Brainfuck.

The Philosophy of "Replacement-Level" Design

I realize my SwiftUI interfaces might be critiqued for their aesthetics. However, as a frequent App Store user, I believe these designs are "a step ahead of replacement-level." Five years ago, I would have been thrilled to have a professional UI designer produce work of this quality.

I don't view these as "apps" in the commercial sense—I have no desire to distribute them. Instead, they are artifacts of agency: ways to force my computer to behave exactly how I want.

Comparison: The Interface Evolution

FeatureCLI / TUINative GUI (SwiftUI)
Origin1970s TeletypesModern OS Frameworks
ConstraintDumb TerminalsHigh-Res Displays
FeelHostile / RigidFluid / Intuitive
DevelopmentFast for nerdsTedious but powerful

Final Thoughts

As a Unix enthusiast, I've always used the command line to bend my machine to my will. But I've discovered that achieving the same result via graphical interfaces is now just as accessible.

The core truth is this: We love TUIs. We build terminal interfaces because we feel we have to, not because it is the optimal choice.

Both CLIs and TUIs are relics of the 1970s, designed around the limitations of teletype machines. They remain outmoded and constrained. As Neal Stephenson noted in a 1999 essay...


Development Checklist:

  • Build MDV.app
  • Master Multivariable Calc
  • Slay the Music Player Dragon
  • Implement Virtual FS
  • Clean up MP3 genre labels from 1997