Always ways of working around it, like saving to files or whatever, but localStorage is a nice interface that works both for Cordova and client-side web apps.

but as you said, it could be overcome by using native apis that store state. it's even imperative in case of secrets, like access tokens and the like.

for client side web apps there's a bigger problem with localstorage. from my experience end users switch browsers and platforms. and they expect consistency from their web sites/apps. this expectation is much more intense than for native apps. so, while practical for developers, i'm not sure it's that welcomed in web land except for always having a local backup or as a temporary storage to alleviate network issues.

Yes. Why not? You can write a Cordova app that doesn't even have a backend.

but since every device is as persistent as its weakest point (e.g. physical damage, loss/theft, etc) shouldn't apps that need to save essential/important data basically give up the argument of persistence because of using localstorage in the first place? your data is one breakdown/loss away from permanent destruction when using localstorage exclusively.

that is why, from my experience, you always rely on the server and only use localstorage as a backup in case the server is down, there's no internet, etc.

claiming massive loss of data because localstorage got emptied is basically saying "our app wasn't designed correctly".

what am i missing?

localstorage disappearing overnight IS a bug. If I put stuff in My Documents folder on Windows and Windows decides to delete it, that IS a bug too. You could argue that I should have backups, and you would be right, but that's no reason for Windows to delete my files, and that is no reason for me to never use my hard disk.

regarding your comparison between a windows folder and localstorage feels a bit exaggerated.

yes, the Chrome team really fumbled it. and yes localstorage and important data should be mutually exclusive.

Local storage and/or SQL DB were touted as features for exactly this use case. That Google did not consider their persistence as that important for the release is perhaps not surprising for a company used to storing all your data in their cloud (not claiming they did so knowingly, just that it's probably in their culture, just as in your comments above).

but unfortunately i don't think your average user has any idea about what you wrote.

It seems like we could say "don't trust this" about any aspect of any platform. Categorizing every application as "really important, don't update the UI until securely written to three AZs" and "totally ephemeral purge every minute" excludes a lot of stuff in the middle. Sure, nothing made by humans is perfect, but many things could be improved. One improvement to localstorage would be to simply not delete all the data.

Saving stuff locally is good for privacy, for performance, for offline-capabilities. You can back up your entire phone LOCALLY, to have a solution of your stated problems (theft, physical damage).

never save important data on a single device. you simply delay the inevitable "i lost my data" scenario.

non-important data on the other hand should have no problems living on a single device. or even localstorage.

and as i said before, i don't think your average user has any ideas about backing up. that's why it almost always comes back to the developers to implement it.

I stored the data on the client using indexedDB, offering an export/import option for manual backups.

I wasn't interested in the data and it's simpler to just store it on the client rather than setting up the infrastructure required to centrally persist this information.

It's really unfortunate that it's not a reliable storage medium.

That's not what it's for, you're just misusing the tool for something it isn't meant to be. It's not a database, it's a cache.

If their app can avoid sending any data to a server and run fully in a web browser offline, they'll do that.