Text Files Are a User Interface

A plain text file is already a user interface. The operating system opens it. Your editor edits it. The filesystem moves, copies, renames, undoes, versions, and shares it. Forty-eight years of Unix tooling already reads it. Reach for an app only when the file truly cannot carry the interaction.

Dave Gauer made the contemporary version of this argument on his personal site in April 2026, in a card titled simply Text files as a user interface¹. The opening line is the whole essay's seed: "Good user interfaces are hard work to make."¹ Good UIs are hard. Text files are already here. The interesting question is not "should we build a UI?" The interesting question is "does the file already do the job, and have we noticed?" The piece spread on Lobsters in June 2026 (43 points within a day of submission) and on Hacker News before that², because the framing names something the audience already half-knew: most personal tools are a text file in a trench coat.

The file is a UI you already know how to use

Calling a file a user interface is not a metaphor. It is a description of what the file can do without further engineering. You open it with the editor you already have. You move it by dragging. You undo with Ctrl-Z. You restore yesterday's version from Time Machine or git. You "share" it by emailing it.

The interface comes for free because the operating system and your editor were already built to provide it.

Gauer's clearest example is a personal one. He keeps an inbox.txt file that catalogs his images, one line per file, with whatever tags he likes. "Simply put, the lack of traditional UI makes this the best image cataloging interface I've ever used. It's as fast as editing text."¹ No menu. No tag tree. No database. The interface is the act of typing in a file, which is something he already knows how to do, has been doing for decades, and will be able to do on whatever computer he owns in 2046.

The pattern generalises. A weekly plan is a file. A reading list is a file. A todo list is a file. The todo.txt format spec puts the philosophy in plain words: "Plain text is software and operating system agnostic. It's searchable, portable, lightweight, and easily manipulated. It's unstructured. It works when someone else's web server is down or your Outlook .PST file is corrupt."³ The repository, started in 2017, holds roughly 3,300 stars in mid-2026³. The format has outlived several note apps that tried to replace it.

The OS already uses this trick on you

The pattern is not a niche personal-productivity hack. The operating system itself uses text files as interfaces, for things you assumed had a real UI. The undo drawer of every Linux desktop is a folder of text files. The authoritative user database on Unix is edited in your text editor. Git uses an editor buffer to confirm every commit.

Open a freshly-trashed file's .trashinfo sidecar; you will find the recoverability metadata in three plain lines. The freedesktop.org Trash Specification v1.0 (January 2014) is explicit: each trashed file gets a metadata text record whose filename "MUST have exactly the same name as the file or directory in $trash/files, plus the extension ".trashinfo""⁴.

The same trick runs deeper. On Unix systems, vipw (short for "vi the password file") edits /etc/passwd by opening it in the user's $EDITOR after taking the right locks¹. The OS's authoritative user database is exposed as a text file through the editor the admin already uses. Git does the same thing one level up: git commit and git rebase -i write a plan to a tmp file, open it in $EDITOR, and trust the resulting bytes. The verb in both cases is "edit the file," not "click the button." The UI is the file, and the editor is your hands.

The reason this works is not aesthetic. It is structural. Doug McIlroy codified it in 1978, in the foreword to the Bell System Technical Journal's Unix issue: "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new 'features.'"⁵ The corollary, often paraphrased separately by Peter Salus⁶, is that the interchange medium between those one-job programs is text. A file in a shared format is what lets vipw, git, your editor, and the filesystem cooperate without any of them being aware of the others. The interface is the file because the file is the contract.

The format outlasts the app

Even when the file's interactive ergonomics are good, the more important property is that the file outlasts whatever app rendered it. The app you write inside today may be free and excellent. The bytes you save in an open format will still be readable when that app is gone. The format is the contract; the app is one renderer.

Mark Pilgrim made the strong version of this case in 2004, in an essay called Freedom 0: "In the long run, the utility of all non-Free software approaches zero. All non-Free software is a dead end."⁷ The argument was about software freedom, but it lands on the file.

Steph Ango, the CEO of Obsidian, put the same observation in a designer's register in 2023, in a short post called File over app: "File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. Use tools that give you this freedom."⁸ One sentence later, the post lands its quotable line: "Apps are ephemeral, but your files have a chance to last."⁸ The choice of medium decides whether the work is portable; the choice of app only decides whether today is pleasant.

That portability is not abstract. The Markdown grammar most of these files share is frozen, dated, and authoritative. CommonMark version 0.31.2 was stamped on January 28, 2024, a numbered, versioned standard maintained by John MacFarlane and a public group of editors⁹. A file written in CommonMark today will be parseable by any conforming reader in 2034 because the spec is a contract independent of any vendor. The reason your .md from 2014 still opens, and your proprietary export from a 2014 startup does not, is the difference between a spec and a feature.

Where the file is the wrong UI (honest limits)

Not every interaction belongs in a text file. The argument is default to the file, not abolish the app. Text files are a poor interface for problems whose primitives are not text: graphics editing, real-time multi-cursor presence, spatial canvases, audio waveforms, video timelines, anything time-triggered or notification-driven. When the interactive part is not text, the file stops being enough.

The video downloader Gauer celebrates as "like having your own step-by-step wizard, but with zero UI programming and no new interface to learn"¹ works exactly because the input is a list of URLs and the output is video files; the interactive part is text the whole way through.

The honest rule is the one the worked examples already imply. A file wins when the interaction is small, named, and writable: when you know roughly what you want to type, you do not need to see it before you say it, and you can write down what you want faster than a UI can offer it to you. A file loses when the interaction is exploratory, continuous, or multi-party in real time: when seeing the next option is the whole point, when you need to drag rather than type, or when two people must edit the same square inch at the same moment.

Sound and pixels are not text streams. A drawing app and a digital audio workstation are not text files in disguise, and pretending otherwise is the failure mode in the other direction. The discipline is symmetric: reach for the file when the file can carry the interaction, and reach for the app when it genuinely cannot. The villain of this essay is not the app. The villain is the shape where every interaction is locked inside an app binary even when the file would have done it, leaving the user with no grep, no git, no undo across sessions, no migration path, and no way to share the bytes without exporting them through the app's permission.

What to actually do this week

The practice is small, and you can start it before lunch. Pick one thing you currently open an app to do, that is mostly text underneath: a reading list, a weekly plan, a list of household errands, the set of films you want to watch. Open a plain .md file in your editor of choice and just type the thing.

Notice, over the next few days, what the file does for you that the app was charging you to do.

1. Pick one app-shaped interaction whose data is text. A list, a plan, a journal, a catalogue. Avoid apps that are genuinely visual or genuinely real-time multiplayer; those have earned their UI.
2. Open one text file. Name it for what it is — reading.md, plan.md, watch.md — and start typing. The first line is the first task. No taxonomy decisions, no fields, no migration script.
3. Add a convention only when you miss one. A +project tag the way todo.txt does. A leading date. A ## week of heading. Conventions are cheaper than features.
4. Use the OS's interface, not the app's. Move the file with the file manager. Back it up by copying it. Search across many files with your editor's project search or grep. Restore with git. The OS has been good at this for decades.
5. Step up to a folder of linked files only when the single file actually breaks. Markdown links between notes is the small step up that keeps everything you liked about the file and adds the two things it could not do: connections, and structure across many files.

The graduation path matters. The argument is not one text file forever. It is the file is the unit. When one file stops scaling, when you need links between notes, structure across many of them, and search across all of them at once, the smallest step that preserves the file's virtues is a folder of small plain-text files that link to each other. The companion piece I Tried Every To-Do App and Came Back to One Text File walks one end of that arc; the deeper file-as-source-of-truth case lives in Your Notes Are Already AI-Ready; the cultural backdrop is in Plain Files Revival.

Frequently Asked Questions

When is a text file a better interface than an app?

When the interaction is small, named, and writable: you already know what to type, the next option is rarely a surprise, and the data is mostly text underneath. Gauer's inbox.txt image catalog is the worked example: he describes it as "the best image cataloging interface I've ever used. It's as fast as editing text"¹. Lists, plans, catalogues, journals, and most personal productivity surfaces fit this shape.

Do I need a note app or just a folder?

Both can work. A folder of plain Markdown files is itself an application if your editor is good enough — the OS opens it, search tools search it, version control versions it, and the format outlasts every vendor. CommonMark v0.31.2 is dated January 28, 2024 and is the shared grammar most note tools already speak⁹. A note app is worth its overhead when it adds something the folder cannot — bidirectional links across many files, a graph view, real-time sync, encrypted sharing — without putting your bytes behind a proprietary export.

Why use Markdown instead of a UI?

Because the UI is hard work to build, and the file is already here. Gauer's opening line is the answer in nine words: "Good user interfaces are hard work to make."¹ CommonMark is a frozen, dated, authoritative spec⁹ every Markdown reader on earth agrees on, which means the file you write today is portable across editors and parseable in 2036. The UI you would have built for that file is one vendor's house style with a finite lifespan.

Plain text vs note-taking app — what is the honest trade-off?

Plain text wins on portability, longevity, and zero lock-in: the file opens in any editor, on any OS, and still opens decades later. Note apps win on links across many files, graph views, real-time presence, and time-triggered features the filesystem does not have. The Pilgrim/Ango framing makes the underlying argument: "Apps are ephemeral, but your files have a chance to last"⁸. The smallest honest rule is to keep the bytes in plain text whatever app you choose, so leaving the app is always a file copy and not a migration.

What do you use for notes, reminders, and tasks?

Usually one text file, until it stops scaling, and then a folder of linked plain-text files. Time-triggered reminders genuinely need an app (the filesystem does not know what 9am means). Free-form notes, plans, reading lists, and tasks belong in files; the todo.txt format has carried this load for nearly two decades and the repository is still active in 2026³. Conventions you invent — a +project tag, a leading date — replace what an app would have charged you a subscription to provide.

Do you need a new note-taking app?

Often, no. If you open an app every day to type plain text into structured fields, the file already does that, and the app is mostly between you and the text. If you need bidirectional links across many notes, real-time sync across devices, end-to-end encrypted sharing, or any time-triggered behaviour, those are the genuine reasons to pick an app — and even then, pick one whose default storage is your files in open formats on your device, so you keep the file's virtues even while you enjoy the app's.

Why are we still using Markdown?

Because Markdown is the interface, not the precondition to one. The grammar is small enough to type, expressive enough for headings and links and code blocks, and frozen by an open spec⁹ so the bytes you save today are not at the mercy of any vendor. The OS reads it, your editor reads it, every reading app reads it, every static site generator reads it, and the language model on your laptop reads it. Markdown is what a file looks like when the file is the interface.

This post builds on Dave Gauer's Text files as a user interface¹, on Mark Pilgrim's Freedom 0⁷, on Steph Ango's File over app⁸, and on Doug McIlroy's 1978 Bell System Technical Journal foreword⁵ — credit, in each case, to the originator, not the resharer. The file is older than any of the apps that try to replace it.

mnmnote.com is a browser-based Markdown editor that keeps your notes on your own device — plain CommonMark files you can open in any editor, the day MNMNOTE is on your machine and the day it is not.