4 ms·

I've had a couple webapps where I needed to use the FS API (which allows users to provide real, accessible folders to a webapp, unlike OPFS). I can't understan

by hoten 2y ago

I've had a couple webapps where I needed to use the FS API (which allows users to provide real, accessible folders to a webapp, unlike OPFS). I can't understand why anyone would want to use OPFS or what problems it solves that a slim interface over IndexDB wouldn't provide. The only use I've had for it has been a almost-ok substitute for the actual FS API (given its the same interface), but since the goal is to allow users to have easy access to your webapp's data, it has to be paired with a cumbersome import/export feature for browsers that only have OPFS. I guess it's probably more performant for FS-like queries (like listing the contents of a directory...), but that performance benefit (for me at least) seems secondary to giving users control over the data.

tommiegannert 2y ago
> To summarize how the OPFS differs from the user-visible file system: > * The OPFS is subject to browser storage quota restrictions, just like any other origin-partitioned storage mechanism (for example IndexedDB API). You can access the amount of storage space the OPFS is using via navigator.storage.estimate(). > * Clearing storage data for the site deletes the OPFS. > * Permission prompts and security checks are not required to access files in the OPFS. > * Browsers persist the contents of the OPFS to disk somewhere, but you cannot expect to find the created files matched one-to-one. The OPFS is not intended to be visible to the user. > * It also has a set of synchronous calls available (other File System API calls are asynchronous) that can be run inside web workers only so as not to block the main thread.
jamesgeck0 2y ago
The OPFS is used in the online version of Photoshop to allow editing large photos without having the entire file (and undo history) loaded into working memory. https://developer.chrome.com/blog/how-photoshop-solved-working-with-files-larger-than-can-fit-into-memory/ https://developer.chrome.com/blog/how-photoshop-solved-worki...
jauntywundrkind 2y ago
It bristles me a lot that browsers are sometimes only offering highspeed FileSystemAccess to OPFS only, not real files. Letting users interact with their files well is a basic decency. Webapps which makes it possible to expose their state & let users see that is a service to users, shows respect. It's good to share your state, bad to hide it in some secret hidden away internal place. As for why not indexeddb, there were some great great details on Notion & their wasm sqlite decision. They tried LocalStorage, sucked, tried IndexedDB, but they said theres a very significant cost per row written or read & that it just was way too slow for their use case of lots of small rows. Really sad to hear, really sucks that the browser once again built some fancy safe secure developers-wont-be-able-to-do-harm approach that ended up being so slow as to be unusable. https://news.ycombinator.com/item?id=40989990 https://news.ycombinator.com/item?id=40989990 The too slow to be usable feels like the last File System API, which lets us do files but in a ridiculously slow fully-buffered form. Because again the spec authors prioritized making a safe secure API that was free of any potential pitfalls that no developer could ever mess up. There-by making something essentially unusably slow except for the trivialest of uses.

by hoten 2y ago

tommiegannert 2y ago

> To summarize how the OPFS differs from the user-visible file system: > * The OPFS is subject to browser storage quota restrictions, just like any other origin-partitioned storage mechanism (for example IndexedDB API). You can access the amount of storage space the OPFS is using via navigator.storage.estimate(). > * Clearing storage data for the site deletes the OPFS. > * Permission prompts and security checks are not required to access files in the OPFS. > * Browsers persist the contents of the OPFS to disk somewhere, but you cannot expect to find the created files matched one-to-one. The OPFS is not intended to be visible to the user. > * It also has a set of synchronous calls available (other File System API calls are asynchronous) that can be run inside web workers only so as not to block the main thread.

jamesgeck0 2y ago

The OPFS is used in the online version of Photoshop to allow editing large photos without having the entire file (and undo history) loaded into working memory. https://developer.chrome.com/blog/how-photoshop-solved-working-with-files-larger-than-can-fit-into-memory/ https://developer.chrome.com/blog/how-photoshop-solved-worki...

jauntywundrkind 2y ago

It bristles me a lot that browsers are sometimes only offering highspeed FileSystemAccess to OPFS only, not real files. Letting users interact with their files well is a basic decency. Webapps which makes it possible to expose their state & let users see that is a service to users, shows respect. It's good to share your state, bad to hide it in some secret hidden away internal place. As for why not indexeddb, there were some great great details on Notion & their wasm sqlite decision. They tried LocalStorage, sucked, tried IndexedDB, but they said theres a very significant cost per row written or read & that it just was way too slow for their use case of lots of small rows. Really sad to hear, really sucks that the browser once again built some fancy safe secure developers-wont-be-able-to-do-harm approach that ended up being so slow as to be unusable. https://news.ycombinator.com/item?id=40989990 https://news.ycombinator.com/item?id=40989990 The too slow to be usable feels like the last File System API, which lets us do files but in a ridiculously slow fully-buffered form. Because again the spec authors prioritized making a safe secure API that was free of any potential pitfalls that no developer could ever mess up. There-by making something essentially unusably slow except for the trivialest of uses.