---
title: "The Case for the Single-File App, Minus the \"Un-Hackable\" Part"
slug: "single-file-web-app-durability"
language: "en"
date: "2026-10-27T20:14:53.724Z"
updated: "2026-10-27T20:14:53.000Z"
description: "A single HTML file is the most durable and portable form of software. It is not unhackable, and the difference matters."
canonical: "https://fix.slopit.io/single-file-web-app-durability/"
tags: ["web", "software", "durability", "security"]
---

Caleb Madrigal makes a claim that sounds like hyperbole until you try to argue with it: the most durable, portable, and secure form of software is a single HTML file.

A Single-File Web App, in his definition, is one static HTML file with no external dependencies — no CDN scripts, no external images, no server components beyond something that hands over the file. JavaScript, CSS, and images can all be inside it. The artifact *is* the application. Copy the file, and you have copied the app.

He is mostly right, and the places where he is wrong are interesting.

## The part that is clearly right

Durability is usually discussed as a property of code. Madrigal frames it as a property of the artifact, which is better. A normal web app depends on a domain, a host, a build pipeline, a package tree, and a set of services. Each of those is a place where the app can stop existing. A single file has none of them: it can be emailed, put on a USB stick, mirrored, or opened from disk fifteen years from now.

His example, Hypervault, is a nice proof: an encryption tool that outputs *another* single-file app containing the interface, the decryption logic, and the encrypted data. The document and the program that opens it are the same object. That is a genuinely better answer to "will I be able to read this in 2040" than any amount of vendor reassurance.

Portability follows for the same reason: anything with a browser runs it, including a phone, a locked-down work laptop, and an air-gapped machine.

## The dependency didn't disappear, it moved

"Zero dependencies" is true at the file level and false at the platform level. An SFWA depends on the browser: on `file://` behaviour, on storage quotas, on APIs that browsers occasionally deprecate, on font rendering, on the security model around local files. That dependency is far more stable than an npm tree, which is the actual argument — but it is not zero.

This matters for the durability claim in a subtle way. Software rot doesn't vanish; it relocates from your dependency graph to the browser vendor's roadmap. That's a much better place for it to live, because browser compatibility is maintained by enormous teams with strong incentives to avoid breaking the web. But it does mean the guarantee is "will probably keep working," not "cannot stop working."

## "Virtually un-hackable" is the sentence I'd cut

Madrigal argues that a downloaded SFWA is essentially unhackable because there is no way to modify it without compromising the whole computer. The first half is right: nobody can push an update to your local copy, and there's no supply chain to poison at runtime.

The conclusion doesn't follow. The browser is a large, actively exploited attack surface, and a local HTML file is still parsed by it. A malicious single file doesn't need to modify itself; it needs to exploit the renderer, or simply convince you to type a password into a lookalike form. Offline execution removes exfiltration, which is a real and underrated benefit — but "un-hackable" is a stronger claim than the architecture supports, and it's the kind of claim that makes people trust the wrong files.

The honest version: a single-file app has a much smaller *supply chain* attack surface, and running it offline removes the network. Those are meaningful. They are not invulnerability.

## The statistic is doing less than it looks

To argue that software rots, the essay cites an "average software lifespan" of six to eight years, attributed to "ChatGPT and Google." In an article about durability, sourcing a number from a chatbot is a small accidental joke. The number may even be roughly right, but it's not evidence of anything specific, and the argument doesn't need it. The architecture comparison stands on its own; the stat weakens it by inviting exactly this objection.

## Where the format earns its keep

Single-file apps are the right default for a specific class of software: tools whose state lives in the file you opened, or in local storage, or nowhere. Calculators, editors, converters, toys, encryption wrappers, visualisations. Madrigal's FuzzyGraph is a 1.3 MB graphing app; that is exactly the shape of thing that should be one file.

They're wrong for anything that needs to send or receive data — he says so plainly — and awkward for anything large enough that a 1.3 MB HTML file becomes a maintenance problem. Inline everything and you lose caching, code splitting, and the ability to patch one module. That's a real cost, just not one that matters for a tool you use for ten minutes.

The modern twist is that generating a single-file app is now cheap. An agent can produce one in a sitting, which makes the format more attractive than it was: the barrier to a bespoke tool is low, and the durability of the result is high.

## The takeaway

The essay's core insight is worth adopting even if you reject its strongest claim: choose the artifact you want to exist in ten years, and let the architecture follow. For small tools, that artifact is a file. Just don't call it unhackable — call it self-contained, offline-capable, and boring, which is a better sales pitch anyway.

*Source: [Single-File Web Apps — Caleb Madrigal](https://gods.art/articles/single_file_web_apps).*