Once upon a time, I ported a turn-based strategy / tactical combat game to the web. The average play time for the game is quite long (many hours), so saving games is an important feature.

PC/Console games have two ways to do "game saves":

1. Save on the machine, keyed to the user thanks to the operating system's file system and
2. Save on the cloud, keyed to the user by some identity provider.

1) is easy to implement (writing and reading a file to disk). 2) is much harder to implement, costs money to run, and requires the gaming machine to have network connectivity.

Web games can do 2) just as easily as PC games. Since this is a hobby project with near-zero players, I don't plan to build my own Cloud service, and I don't trust any Cloud-hosted "gaming" API to be stable enough or not get killed in the future. So that leaves me with saving and loading games locally.

Unfortunately, browsers have a major road block: they do not allow native file system access. Back a decade ago when I started to write the game, it looked to me like browsers would eventually implement this: progress on browser compatibility and "native app" capabilities were pretty breathtaking at that time.

So I put up with some jankiness: To load a savegame, pick a file from your computer. To save a game, the web app downloads the savegame file to your computer. That kind of sucks and doesn't allow a save-as-you-play experience, but good enough for now. I threw in more jank with the option to use Google Drive API as well for a cheap-o version of a Cloud service. (Why not Play Games API? Because they eventually killed their Web API. See "stable forever" above.)

All this jank was an acceptable workaround until browsers caught up, or so I thought.

Here we are a decade later. Though Chrome desktop has proposed and implemented the File System Access API for native file access, it's not quite enough when compared to what native apps can do - and other browser vendors have adamantly refused to implement true native file access, making this capability a sad bloated corpse floating in a lake. I'm saying native file access is dead in the water.

Why didn't I just use localStorage or IndexedDb for this? Well, for one, it was stubbornness and naïvety. For two, I worried about how much data I could store reliably. For three, I thought that users would expect their saved games in Chrome to be playable in Firefox or Safari on the same machine or want ways of passing their saved games around.

The fact my savegames are something like 35k means that storage was never really a concern.

The fact that most users only ever use a single browser, means I don't need to really worry that much about portability.

It's actually pretty straightforward to implement a virtual file system in IndexedDb that works good enough. Heck, Apple did it as some weird peace offering to people who wanted File System Access. [As an aside: as far as I can tell, an origin-private file system offers zero user-facing benefits over IndexedDb, you're just trading one API for another... so it's a devex offering. True native file access offers user benefits, such as backing up your save games, hacking, modding, sharing outside of the browser]

So in the end, I just wrote my own storage service that loads/saves games to an IndexedDB store in the browser. These days, superior user experience trumps web specification idealism for me every time.

P.S. I'm no security expert. I'm sure Mozilla and Apple have good reasons for rejecting the File System Access API. I'm just sitting here loving the technology of the web (zero install, the APIs, JavaScript/Typescript) and the developer experience but wishing I had all the perks that native apps do.

P.P.S. I was surprised to learn that an IndexedDB instance for a page at foo.net is different than the IndexedDB instance of an iframe of foo.net hosted at bar.net. That's a subtlety I hadn't thought through.