Three Old Web Features Really Died. A 200-Line File Can Dodge Them

Try it, on paper: open any old single-file tool of yours and search it for these strings: openDatabase, <applet, <embed, showModalDialog, document.write, and async: false or open(..., false). Every hit is a candidate failure. A file with zero hits has dodged the named list. That is a one-minute check, and this post says how much it proves. (This post has no Lab run. Every count is hand work from the records I list.)

Question

In an earlier post I said a single HTML file outlives a framework app, but only if it skips the CDN. Critics said I never named what actually breaks. So here is the narrower question. Of the five file features that broke old web tools (synchronous XHR, document.write, applets, openDatabase, showModalDialog), how many appear as real removals in browser records, and when?

My thesis going in: a 200-line file is safe because it avoids a short, named list, not because it is simple. I now think that holds, with one correction. The list is shorter than I feared.

Data and where it came from

I read six public records. I did not run any code.

• Chrome's own Web SQL removal post [1].
• The NPAPI article, for plugin removal dates [2]. Java applets ran through this plugin model. The article does not say "applets" outright, so that link is my inference.
• A trade-press report on showModalDialog in Chrome 37 [3].
• Chrome's document.write intervention post [4] and the MDN page [5].
• MDN on XMLHttpRequest.open [6].

Two gaps. First, I could not load the MDN page for showModalDialog: the fetch returned the newer <dialog> text. A search summary said Chrome removed the method fully in Chrome 43, and it gave several different Firefox versions. That is one weak source, so I use only the Chrome 37 fact [3] and give no Firefox version. Second, my search found no Chrome Status entry for synchronous XHR. I rely on MDN's wording [6].

Method

I sorted each feature into one of three states, using the source's own words:

1. Removed: the call or plugin no longer works in a current stable browser.
2. Intervened: the browser blocks the feature in a named narrow case, and the call still works elsewhere.
3. Deprecated only: a warning or a note, and the feature still runs.

Then I wrote down the first major browser release that made the feature fail. That gives a date I can compare with a tool's age. The five-item list is mine. I took it from memory of what broke old tools. It is a list I committed to, not a random sample. I treat it as a test list, not a population.

Result

Feature	State	Record
Applets (via NPAPI plugins)	Removed	Chrome dropped NPAPI in September 2015. Firefox 52 (March 2017) dropped it except Flash. Full removal in Firefox 85 (January 2021) [2]
openDatabase (Web SQL)	Removed	Gone in insecure contexts at Chromium 110. Gone in all contexts from Chromium 119. Trial ran 117 to 123 [1]
showModalDialog	Removed (Chrome)	Support turned off in Chrome 37, with a temporary enterprise policy [3]
document.write	Intervened, not removed	Chrome 55 skips some injected scripts on 2G. Scripts must be top-level, cross-site and parser-blocking [4]. MDN says deprecated but still in the HTML spec [5]
Synchronous XHR on main thread	Deprecated only	MDN says many browsers deprecated it. Workers still allow it [6]

Count: 3 of 5 removed, 1 intervened, 1 deprecated only. Hand check: 3 + 1 + 1 = 5.

For the share removed, 3 of 5, the 95% Wilson interval is about 0.23 to 0.88. Hand work: center = (0.6 + 3.8416/10) / (1 + 3.8416/5) = 0.5566. Half-width = 0.3258. The interval is huge because n = 5. Also, the five items are a chosen list, so the interval says little about "web features in general". I show it only so nobody reads 60% as a rate.

What the dates say about a 2016 tool

Put the dates against a tool written in 2016 and opened in 2026:

• Applets: already dead in Chrome since 2015 [2]. A 2016 tool using them never worked in Chrome.
• showModalDialog: off in Chrome since Chrome 37 [3], well before 2016.
• openDatabase: the only one of the five that broke inside the 2016 to 2026 window, at Chromium 110 and 119 [1].
• document.write and synchronous XHR: still run, with warnings or narrow blocks [4][5][6].

So for Chrome, a tool written in 2016 could have lost at most one of the five in its first ten years, and that one was a storage API. That surprised me. I expected the list to bite harder. Most of the old breakage hit tools written before 2014, not tools from the year I sample.

Why this supports the single-file claim, narrowly

A file with no hits avoids the three removals. It also avoids the two live risks. The two live risks matter more for the next ten years than the dead ones, because they are the ones that can still move.

A built app is not immune to these features. The bundle can include old libraries that call document.write or synchronous XHR, and the author may never see them. That is my reading, not a measured rate. A single file you wrote in full is searchable in a minute. A lockfile of hundreds of packages is not. That is the real asymmetry: not simplicity, but auditability against a named list.

Sensitivity: which assumption moves the result most

The list itself. If I add features that I did not pick, the 3 of 5 count changes at once. A list built from other vendors' removal pages could give 5 of 8 or 3 of 9. The result is only as good as the choice, and I chose it after the fact from tools I knew had broken. That is selection bias. Of all the assumptions, this one moves the result most. The survival run fixes it: I will hash the feature list before I look at any repository.

Chrome as the only browser. Four of five rows rest on Chrome records. Firefox and Safari have their own dates. For showModalDialog my sources disagreed on the Firefox version, so I did not use it. If a reader opens the file in a browser that removed a feature earlier, the removed count for that reader is higher.

What "removed" means. I counted applets through NPAPI. If you count only the explicit <applet> tag, the row's date and source change. If you move document.write into "removed" because of the 2G block, the count becomes 4 of 5. I do not, because the call still runs in the common case [4][5].

The context of the file. I did not check whether a page opened from disk behaves like one on an insecure web origin for Web SQL. The Chrome post separates insecure contexts at 110 from all contexts at 119 [1]. I did not test either. A reader opening a local file could land on either date. The gap is nine releases, so it matters for dating a failure.

What I still do not know

I have no survival rate. I have a list and dates. The earlier ten-year audit multiplied layer odds, and critics showed that those layers are correlated. This post does not repair that. It shrinks one input: the chance that a named browser feature kills a plain file.

One forecast, since the two live risks are checkable. I put 0.85 on this: on 2036-12-31, Chrome stable will still run a top-level inline <script>document.write("x")</script> in a page loaded from disk and show the text "x". I will resolve it myself by running that line in Chrome stable on that date. I will not forecast synchronous main-thread XHR until I find a Chrome Status entry that gives a firm criterion.

My confidence in the broad claim that single files outlive framework apps stays at 0.65. This post moves the reason, not the number. The file lasts because the removal list is short and I can grep for it. Whether the CDN, the browser and the build tool leave the same short list to the other side is what the survival run has to measure.