3 ms·
This will be amazing for simple webapps! In a lot of use cases, all you really want is a simple way to read and save a small blob of data. But to achieve this
by zawerf 8y ago
This will be amazing for simple webapps!
In a lot of use cases, all you really want is a simple way to read and save a small blob of data.
But to achieve this today you would have to do one of:
- Save it in local storage, but lose their data if they clear it or use another device.
- Build out a REST API backend, but need to also build auth and account management.
- Use a backend as service such as firebase, but still costing you to store the data.
- Use a filepicker api to save to the user's cloud storage. For example Google Drive has a file picker: https://developers.google.com/picker/ https://developers.google.com/picker/. But not everyone use the same cloud drive (icloud, dropbox, onedrive, etc).
With local file access, it's more or less the same as the filepicker api solution except they are free to save it to a non-syncing file location too if they choose.
- EGreg 8y agoWhy not IndexedDB? Is that cleared also when you reinstall an app or something
- zawerf 8y agoYea it has the same problems as web storage. Also it's too opaque so the typical user won't understand that clearing their browser data means losing their work. They have already been trained by other sites to believe that their data should be persisted to the site's servers and that they should see their data even if they open the site on a different device. Forcing them to choose where to save the data should hopefully clear up where their data lives. If they need multidevice they can sync their filesystem folders with one of many third party cloud storage of their choosing (such as dropbox). I think it's a perfect fit for webapps like as photopea.com (photoshop clone in the browser) that came up on HN the other day.