I wrote a couple of weeks ago about Small Utilities. Near the end, I explained that I was focusing on stateless utilities becuase they can dodge the question of where to store state. If storing state is not required, the utility can be distributed as a static file. This is an issue unique to web apps, though. Back in the days of DOS and Windows 3.1, you ran programs off of floppy disks. Later, hard drives, and even later smart-phones with flash memory, when "programs" became "apps". And then web, when "web apps" carried the taint of trying to be like a program used to be, and usually failing in various annoying ways, but being so easy to access that all someone needs is a link. One of the most critical ways was that web apps required that you store your data on the server, and all the costs that come with that. But what if you didn't have to store your data on the server, but could still benefit from a web app's ease of distribution?

The browser would gain the ability to run programs designed to render as a web page and store data to the browser's own storage, which could be seamlessly synced to all the devices using end-to-end encryption (I'm thinking of Firefox Sync here, but I think Chrome has a similar thing). It would have to leverage a special area of localstorage, I expect, since cookies and localstorage are not generally storing data that apps expect to be copied across machines.

The browser would have to be crafted to provide three additional guarantees about localstorage:

1. A per-site setting that would "protect" the localstorage for that site from being cleared.
2. Browser sync services that would support accepting a subset of localstorage to be synced along with every thing else like browser history, favorites, settings, credit cards, open tabs, logins/passwords, and addons.
3. Some way for Javascript code to tag localstorage writes as "syncable", so that they would sync along with the rest of the browser data in the above system.

This would unlock a whole host of static apps that can work offline and automatically sync with all your devices when they come back. If the 5MB per site localstorage limit could be lifted as well (and subsequent performance issues were addressed), static sites could be a very strong offering. Of course, with them being so easily copied, perhaps the biggest issue is how to monetize such a thing.

One way would be to notmonetize it. Mozilla (acting as a non-profit), could develop these static apps designed to use all this, and build the necessary features into the browser (on an experimental branch) and try it out. If it works out, it's possible there could be a way to monetize by selling a monthly service to sync large amounts of localstorage to everyone's devices, while leaving the static apps that use that storage open source.

Getting a browser vendor to take this on might be challenging. Without their cooperation, you might be able to jam pouchDB into the page (or possibly an addon if more storage space were immediately desirable) and prompt the user for credentials. This dodges syncing and localstorage, but a developer would still have to write the app itself. It seems like this is possible right now, but the list of known users of PouchDB seems thin to me. Where's all the notebooks, word processors, and spreadsheets? Again, I suspect monetization, and also collaboration: one benefit of storing all your data on someone else's server is that they can serve it to others so you can collaborate on it. There is not direct path to such a feature with a localstorage-syncing approach.

But syncing localstorage (or PouchDB) for static apps can replicate the functionality of programs that would run on DOS or Windows 3.1, which the additional feature that it is available across all devices a browser can run on, and syncs the data to all those devices, all while not sacrificing offline functionality.