Skip to content
Stories

Essay

The slow death of the file

For forty years, the file was the unit of digital work. In 2026 it is increasingly a legacy artifact — a folder icon clinging to a metaphor most software no longer honors.

Mira VossEditorWednesday, May 27, 20268 min read

Open the Documents folder on your computer. Look at the date-modified column. Count, honestly, how many of those files you have opened in the last thirty days. The number is almost certainly smaller than it would have been five years ago, and dramatically smaller than it would have been ten. The folder still exists. The files are still there. But the work has quietly moved somewhere else, and the folder is increasingly an archive of a way of working that nobody is going back to.

The file was the central abstraction of personal computing for roughly forty years. From 1984 to about 2014, the question 'where is your work' had a literal answer — it was a file, in a folder, on a disk, with a name you chose and an extension you may or may not have understood. The file was the unit of saving, sharing, copying, deleting, attaching, syncing, backing up. Every action you took had a file as either its input or its output. The file was the noun. Everything else was the verb.

In 2026, this is no longer how most of us work. The shift has been quiet enough that it is easy to miss, but it is real, and the consequences are larger than they appear.

What replaced the file

Most modern productivity apps no longer center the file as their unit of work. Notion does not have files; it has pages, in a tree, in a workspace. Linear does not have files; it has issues, in projects, in teams. Figma technically has files — they are still called files in the interface — but the file is a multiplayer URL, not a thing on a disk. Google Docs and the Office 365 web apps follow the same pattern. The file is a record in a database that happens to render as a document.

Even the apps that still use file metaphors have decoupled them from local storage. The 'file' in Google Drive is a row in a Google datastore with a UI that pretends it is a file. You cannot find it on disk. You cannot back it up the way you used to back up files. You cannot send it as an attachment in the old sense — the right way to share it is to share a link to the place it lives.

Why this happened

Files were a great abstraction for single-player computing. They were a terrible abstraction for multiplayer computing, because the moment two people need to be in the same document at the same time, you have to invent an entire syncing-and-merging layer on top of the file format. Office, Photoshop, Sketch, every desktop tool that tried to bolt collaboration onto a file-based architecture in the 2010s discovered the same thing: it does not work. Collaboration is not a feature you add to a file format. It is a property of the system, and the system that supports it natively does not need files in the first place.

The collaborative web apps that won their categories — Figma, Google Docs, Notion, Linear — all made the same architectural bet. They stored the work as a structured database record, served it from the cloud, and resolved concurrent edits at the document model layer. The file became, at best, a UX convention preserved for backwards compatibility. At worst, it became a hostile thing: a serialized snapshot that does not match the live state, that diverges the moment you download it, that cannot be re-uploaded without confusion about which version is canonical.

What we lose

The file had genuine virtues, and most of them have not been replaced.

Ownership, in the unambiguous sense

A file on your disk is yours. You can copy it. You can back it up. You can open it on another machine without asking anyone's permission. If the company that made the software vanishes tomorrow, the file is still there, and you can probably find a way to read it. This is not true of work that lives in a cloud workspace. If the company vanishes, the work vanishes with it, modulo a hopefully-functional export feature.

Portability across tools

A Word document opens in Word, Pages, Google Docs, LibreOffice, Notion (clumsily), and TextEdit (badly). A Notion page opens in Notion. The collaborative-database model has, in practice, traded interoperability for collaboration. The tradeoff was probably worth it for most users. But pretending it did not happen is a small dishonesty that the industry collectively keeps committing.

The locatability of a thing

When you needed to find a file in 2008, you opened a Finder window and looked. The folder structure was, for many of us, a memory palace — a spatial representation of the work we had done. That has been replaced by search, which is faster in most cases and worse in some specific ones, particularly the case where you do not remember the words you used and only remember where the thing was.

What we gain

It would be unfair to present the trade as purely a loss. The thing that replaced the file works better for most modern work in most measurable ways.

  • Collaboration is real, not bolted-on. Two people in the same document is the default mode, not the awkward exception.
  • Versioning is automatic. You do not need to remember to Save As. The history is the system, not a discipline.
  • Cross-device access is free. The same work, on your laptop, your phone, the borrowed machine at a hotel desk — without thinking about syncing it.
  • The cost of trying a new tool is low, because the unit of work is portable in URL form, not in disk-image form.

These are real wins. They are also wins that mostly compound for teams. Solo users get less of the upside and most of the downside, which is one reason a small but stubborn rump of solo writers, developers, and designers have stayed on file-based tools even as their teams have moved.

The categories where the file still wins

There are still corners of the work where the file is the right unit:

  1. 1Code. Git is, in essence, a sophisticated file-versioning system. The file is the unit. The collaborative-database model has not won here and probably will not — the affordances of plain text files have proven extraordinarily durable.
  2. 2Photo and video originals. The high-resolution master is a file. It will be a file for a long time. Even cloud-native tools like Lightroom essentially treat the cloud as a sync target for files that were originated on a disk.
  3. 3Long-term personal archives. The things you want to still be able to open in 2046 are the things you want as files, in formats that have been stable for decades, on storage you control. Cloud workspaces are not the right home for these.

The pattern is consistent: the file survives wherever the work is solo, the format is durable, and the lifespan exceeds the lifespan of the company that made the software. These are not small categories. They are also not where most knowledge work happens.

What this means for how we name things

One of the small, telling shifts: most modern web apps have stopped letting you name the root unit of work. You do not name a Linear; you name an issue inside Linear. You do not name a Slack; you name a channel. You do not name a Figma; you name a file inside a project inside a team. The thing-with-the-name has receded several levels into the system, and the system itself is just the name of the company that built it.

This is, on its surface, a tiny UX detail. It is also a quiet revolution in how we think about our work. The work no longer has a name we chose. It has a position in a hierarchy we navigated to. The naming layer has been pushed down into the leaf nodes, and the leaf nodes do not always feel like the unit of work either — they feel like rows in a table that happens to render as a card.

What we recommend, given all this

We do not have a clean prescription, because the trade is genuinely complicated. A few rough rules we have arrived at after thinking about it for too long:

  • If the work is collaborative and short-lived, use the cloud-native tool. The file model is the wrong tool for this job.
  • If the work is solo and durable, prefer file-based tools, or at minimum tools with strong, lossless export. Markdown for writing, Git for code, raw image formats for visual work.
  • Read the export feature before you commit to a new workspace tool. If the export is hostile, the company has decided your work belongs to them. Act accordingly.
  • Periodically — once a year is enough — back up the cloud workspaces you care about, even if the tool does not technically need you to. Companies disappear. Service tiers change. The export you can do today is not guaranteed to be the export you can do in eighteen months.

The deeper change

The file is dying because the underlying model of personal computing is changing. The file made sense when the computer was the thing, the disk was the place, and the work was a noun you could pick up and put down. The model now is closer to: the network is the thing, the workspace is the place, and the work is a stream you join and leave. Files are nouns. Workspaces are verbs. The grammar of work has changed.

Whether this is good or bad is a question the next decade will mostly answer in the negative — the cost of having no nouns, no possessable artifacts, no objects-of-work that survive their tools — only becomes visible the first time you lose a workspace you cared about. By then it is usually too late to wish the file had lived a little longer.


The catalog above is, in a small way, a record of this transition. Almost every app on it is a workspace, not a file editor. The handful that still center the file — code editors, the few remaining markdown-first writing tools, the handful of local-first design tools — are increasingly the holdouts. The holdouts are sometimes the most interesting apps in the catalog. It is worth noticing when something is a holdout, and why.

Tags

filesdocumentsdesignmetaphoranalysis

More from the catalog

Apps that come up in this story.

1

Notion

Productivity

4.7·210K
Launch
2

Figma

Design

4.9·142K
Launch
3

Linear

Productivity

4.8·38K
Launch

Keep reading

More stories from dotstore.

See all