I Accidentally Wrote a Filesystem Driver. For a Browser. 🤔

Source: Dev.to

Problem Overview

Data vanished. No error, no warning, no stack trace—just gone.

Your app writes files using the File System Access API, one of the most exciting browser features in years. A user picks a folder, you write to it, cleanly and natively, without a server. The dream, right?

Except on mobile, the dream often dies quietly.

• The browser process is killed in the background (common on Android when memory is tight).
• A writable stream is mid‑write when this happens.
• No error is thrown; the write simply doesn’t complete.

Failure Modes

1. Process kill – The OS kills your process, and the in‑flight write disappears.
2. Stale handle – You reopen the app, but the file handle you previously obtained is now stale.
3. Concurrent writes – Firing multiple writes at once leads the File System Access API to race them; most silently fail because the API doesn’t serialize the operations.

All three failures are silent and result in data loss.

Solution

I addressed each failure mode with a small durability layer for mobile browsers:

• Write‑ahead buffer – Queues data before it reaches the filesystem.
• Per‑filename queue – Ensures writes to the same file are serialized.
• IndexedDB fallback shelf – Stores pending writes safely when the filesystem is unavailable.
• Recovery mechanism – Replays shelved writes on the next app wake‑up.

Together these components form a write‑ahead logging (WAL) system, similar to what PostgreSQL uses to survive crashes, but implemented inside a browser tab.

Reflections: The Browser as an Operating System

These concerns—write ordering, process lifecycle, I/O durability, crash recovery—are traditionally solved at the OS level, not in web apps. The uncomfortable truth is that the browser already functions as an OS:

• It has a process manager (tab lifecycle, background kill policies).
• It provides its own filesystem, persistent storage, compute pipeline, and process isolation.

Most frameworks still treat the browser as a dumb UI layer on top of a server, but the platform has quietly evolved. Wrappers like Electron, Tauri, and Capacitor merely expose the browser’s existing OS‑like capabilities rather than adding new ones.

Implications for Developers

We’re in a transitional moment. The browser runtime is powerful enough to be a first‑class OS, yet many developers still build as if it’s just a view layer. Those who recognize this can start building system services—filesystem drivers, process managers, durability layers—directly on top of the browser.

The Gnoke Suite aims to provide such a system layer that runs as the browser, not merely in it. This subtle shift can change how we architect web‑based applications.

See the Code

If you want to see a practical implementation of a browser filesystem driver, check out:

• gnoke‑savenative on GitHub

Call for Feedback

If you’ve encountered similar issues—silent write failures, stale handles, mobile process kills—please share your experiences in the comments. I suspect many have faced these problems but few have written about them.