Why I Write in Plain Text

A few days ago, I decided to start an article about my writing setup. Over the years I have dialed it in, and today I have a pretty neat workflow. As I started on that piece, though, I realized that I had never talked about why I write in plain text. Most aspects of my workflow traces back to that choice, so today I want to explain some of the reasons I made it.

The Conventional Route #

Most people write in rich text editors or word processors. These applications create plain text files, then add a bunch of hidden code to cause the display of italics, lists, images, and tables. This makes writing easier, but it has a few serious downsides. For one, that invisible information can become bloated and unpredictable if the program does not manage it well. I used to write posts in raw HTML on my WordPress site, because I spent too much time tracking down weird formatting errors with its built-in editor. That hidden information may also mean different things depending on the machine, which can make creating an article on one computer and then editing it on another tricky. Some companies try to fix this by using proprietary code to control file formatting, which makes it impossible to view or edit these documents without special software.

Many blogging platforms include some sort of built-in rich text editor, which compounds these problems. These editors have all the same problems I outlined above, plus blog engines also tend to abstract the user’s file system: instead of storing the “Hello World!” post as a file on your computer, they will store it in a database. This adds another layer of abstraction to the mix: one more opportunity for something to go wrong, and one more layer I might have to dig through to fix it. Taken together, the alleged simplicity of a blogging engine with a rich text editor did not outweigh the serious drawbacks of unpredictable performance, cross-platform inconsistency, vendor lock-in, and an opaque storage schema. I planned to pour a great deal of time, energy, and effort into writing, and I could not risk losing all that work if some link in the chain failed.

The Unconventional Route #

Instead, I chose to write in plain text. I made this decision for a few reasons, future-proofing my writing primary amongst them. I could take any one of these articles to a computer from the 1980s and read it; forty years from now, whatever machines we use then will still open that file. No one owns this format, and anything that turns on will read it. I could not accept the possibility of someday finding thousands of hours of work locked in a file time had made unreadable, so I picked a format that guaranteed I would never have to. I also chose plain text for its portability. Its simple, open, and predictable nature means I do not need a special program to use these files. I can view, edit, and save them on any device, with built-in applications. I can write on my home computer, access those files on a work machine, or even create full-fledged articles on my phone.

Plain text future-proofed my writing, works everywhere, and will stay readable as long as computers stay running. It did not win out in style, though: it does not support italics, images, and all the other features I needed to write readable articles on the web. John Gruber and Aaron Swartz solved that problem in 2014 with Markdown. The project outlines a set of rules for formatting plain text files using special characters, like the asterisk. Once formatted, a small program converts those files into HTML for use on the web. Together, I now had a setup that allowed me to store my work anywhere, access it from anywhere, and never worry about an editor bungling my formatting, or database corruption losing all my work. I had found my perfect system.

I started looking at editors next. Remarkable functionality across the board soon made this a reason to stick with the format all its own. Features I would not have dreamed of in a word processor come standard in this space — things like Regular Expression search and replace, multiple cursors, automatic indexing, support for projects, and extensive customization and extensibility. I soon learned that I could do everything with a text editor I could do with a word processor, and then a thousand other things, too. These apps have a bit of a learning curve to them, but their immense value far outweighs the small amount of time it will take to adapt.

I now had a way to create and style plain text files, but no way to preview them. I settled on Brett Terpstra’s Marked 2. This app parses Markdown and includes helpful proofing tools and readability statistics. It let me visualize complex words and word repetition, and gave me helpful figures that gauge my writing’s complexity. It even estimated the number of years of formal education needed to understand my articles. Marked 2 soon became one of my favorite tools, and I considered it indispensable for years until I replaced it with a program of my own design in early 2019.

When I decided to get serious about writing, I had a decision to make. I could have used a blogging platform, or written in some form of word processor, but the minor benefits of the conventional route did not outweigh the significant costs. Plain text gives me portability, I learn cool new things about my phenomenal editor of choice every week, and dedicated proofing software polishes my work to a level I would have never achieved any other way. I write in this format because — no matter how I looked at it — plain text beats out everything else, no contest.