4 ms·

IndexedDB does indeed suck, but there's really no alternative to it if you want Safari and Firefox support. Fortunately, in Chrome we have the FileSystem Access

by feross 5y ago

IndexedDB does indeed suck, but there's really no alternative to it if you want Safari and Firefox support. Fortunately, in Chrome we have the FileSystem Access API which has a feature that lets you write into an "origin private" store, similar to how IndexedDB partitions storage per origin. There's even recent work to add even higher performance APIs into the Filesystem Access API and the reception from Firefox and Safari has been positive. Really early work is happening here: https://github.com/WICG/storage-foundation-api-explainer https://github.com/WICG/storage-foundation-api-explainer and the latest proposal is here: https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec/edit https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUV...

dmitriid 5y ago
> There's even recent work to add even higher performance APIs into the Filesystem Access API and the reception from Firefox and Safari has been positive. Positive as in: "FileSystem Access is a significant security risk and we're not going to implement this"? https://www.chromestatus.com/feature/6284708426022912 https://www.chromestatus.com/feature/6284708426022912 Positive as in "No, we don't want fifteen different file access apis, and we don't think Storage Foundation API is going anywhere"? https://www.chromestatus.com/feature/5670244905385984 https://www.chromestatus.com/feature/5670244905385984 And even though this is a draft created and authored exclusively by Googlers, even other Googlers are confused: https://github.com/WICG/storage-foundation-api-explainer/issues/8 https://github.com/WICG/storage-foundation-api-explainer/iss...
- feross 5y ago
  Storage Foundation is being merged with the Origin Private part of the Filesystem Access API specifically to address feedback from Safari and Firefox teams about too many File APIs on the web, and if they only implement the Origin Private part of the spec there’s no more risk than IndexedDB since it doesn’t interact with the real file system.
  - dmitriid 5y ago
    > Storage Foundation is being merged with the Origin Private part of the Filesystem Access API specifically to address feedback from Safari and Firefox teams about too many File APIs on the web Good. Still doesn't mean there's positive feedback. > if they only implement the Origin Private part of the spec there’s no more risk than IndexedDB since it doesn’t interact with the real file system. If. Or it may go the HID way: https://news.ycombinator.com/item?id=27512354 https://news.ycombinator.com/item?id=27512354 I wouldn't hold my breath for "positive feedback" on these APIs.
- pimterry 5y ago
  > FileSystem Access is a significant security risk and we're not going to implement this Right now the Mozilla position is 'defer', not 'harmful'. See https://mozilla.github.io/standards-positions/#native-file-system https://mozilla.github.io/standards-positions/#native-file-s.... That means yes, they're not implemented today, but they're open to doing so later on, given further specification development and real-world investigation to confirm that the security implications are minimal. > No, we don't want fifteen different file access apis Looks like there is some ongoing work to synchronize these APIs to resolve that concern: https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec/edit https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUV... --- I 100% agree Google is too aggressive at publishing and releasing these features without widespread consensus from other vendors. If they were doing so with just origin trials or behind a flag that would seem reasonable to me, but the widespread release is surely going to cause problems for these specs, when they must be aware that further development and changes is going to be required. I'm not clear how they intend to mature these standards without breaking the early adopters. I don't agree they're not desirable features though. Honestly I desperately wish Safari & Firefox would engage more and drive these specs themselves! It would be better to get their voices in the decisions that'll define these specs, rather than letting Google define the future of the web all by themselves. There's clearly demand for these features (read the comments of https://github.com/mozilla/standards-positions/issues/154 https://github.com/mozilla/standards-positions/issues/154 for some examples). It would be better to have privacy and security baked in with input from a broad group of actors (I think we can all agree that Firefox is going to be a more useful voice than Google in that sense). It's not helpful to let Google run off and write every standard themselves, with other browsers watching from the sidelines until it's sufficiently done (and unchangeable) and then having to either adopt the existing standard as-is by necessity or to refuse to support many real world web applications (for as long as that's tenable). Make no mistake - Chromium has the market share to be a workable target, and these APIs work well for developers and are genuinely useful. They will be used. There will be (in some areas there already is) a whole world of web apps using these APIs which only work in Chromium by necessity, no matter how much they'd like to support other browsers. As those get adopted by users, that's only going to drive the web further towards Chromium, until other browsers have to die or adopt the (entirely Google-written) standards themselves too to support the next generation of webapps. This is happening on desktop in some areas already. In IDEs, for example - if you buy any IoT based on Espruino, the primary dev tool only works in Chrome due to WebUSB/WebBluetooth (https://www.espruino.com/Web+IDE https://www.espruino.com/Web+IDE), while tools like Godot Editor are already talking about Chrome-only save/load support using these filesystem APIs (https://godotengine.org/article/godot-editor-running-web-browser https://godotengine.org/article/godot-editor-running-web-bro...), and I'd be extremely surprised if GitHub Codespaces and other tools aren't looking at doing the same. These are popular tools - many users want to use them, and they will have to switch to a Chromium-based browser to do so. Mobile is somewhat protected due to Safari being the only option on iPhone, but I wouldn't be surprised if the ongoing antitrust cases force them to open that up to make PWAs look like a plausible app store competitor, and the exact same thing happens there. WebExtensions is a case study of the same effect in the past. Chromium has so much weight that once they fully design and adopt an API and build an ecosystem around it, other browsers have to follow or get cut off. If Firefox & Safari had engaged with WebExtensions much earlier, they could have been driving it themselves and building consensus. Instead, they've had to copy every Google API while just tweaking around the edges. One exception, interestingly: Brave is doing some intriguing work on driving decentralization APIs for the web (native Web3, native IPFS). It's early days, but I'm hopeful that this might have the same effect in the opposite direction for those features!

by feross 5y ago

dmitriid 5y ago

> There's even recent work to add even higher performance APIs into the Filesystem Access API and the reception from Firefox and Safari has been positive. Positive as in: "FileSystem Access is a significant security risk and we're not going to implement this"? https://www.chromestatus.com/feature/6284708426022912 https://www.chromestatus.com/feature/6284708426022912 Positive as in "No, we don't want fifteen different file access apis, and we don't think Storage Foundation API is going anywhere"? https://www.chromestatus.com/feature/5670244905385984 https://www.chromestatus.com/feature/5670244905385984 And even though this is a draft created and authored exclusively by Googlers, even other Googlers are confused: https://github.com/WICG/storage-foundation-api-explainer/issues/8 https://github.com/WICG/storage-foundation-api-explainer/iss...

feross 5y ago
Storage Foundation is being merged with the Origin Private part of the Filesystem Access API specifically to address feedback from Safari and Firefox teams about too many File APIs on the web, and if they only implement the Origin Private part of the spec there’s no more risk than IndexedDB since it doesn’t interact with the real file system.
- dmitriid 5y ago
  > Storage Foundation is being merged with the Origin Private part of the Filesystem Access API specifically to address feedback from Safari and Firefox teams about too many File APIs on the web Good. Still doesn't mean there's positive feedback. > if they only implement the Origin Private part of the spec there’s no more risk than IndexedDB since it doesn’t interact with the real file system. If. Or it may go the HID way: https://news.ycombinator.com/item?id=27512354 https://news.ycombinator.com/item?id=27512354 I wouldn't hold my breath for "positive feedback" on these APIs.
pimterry 5y ago
> FileSystem Access is a significant security risk and we're not going to implement this Right now the Mozilla position is 'defer', not 'harmful'. See https://mozilla.github.io/standards-positions/#native-file-system https://mozilla.github.io/standards-positions/#native-file-s.... That means yes, they're not implemented today, but they're open to doing so later on, given further specification development and real-world investigation to confirm that the security implications are minimal. > No, we don't want fifteen different file access apis Looks like there is some ongoing work to synchronize these APIs to resolve that concern: https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUVSNxqREnE98malHYwWec/edit https://docs.google.com/document/d/121OZpRk7bKSF7qU3kQLqAEUV... --- I 100% agree Google is too aggressive at publishing and releasing these features without widespread consensus from other vendors. If they were doing so with just origin trials or behind a flag that would seem reasonable to me, but the widespread release is surely going to cause problems for these specs, when they must be aware that further development and changes is going to be required. I'm not clear how they intend to mature these standards without breaking the early adopters. I don't agree they're not desirable features though. Honestly I desperately wish Safari & Firefox would engage more and drive these specs themselves! It would be better to get their voices in the decisions that'll define these specs, rather than letting Google define the future of the web all by themselves. There's clearly demand for these features (read the comments of https://github.com/mozilla/standards-positions/issues/154 https://github.com/mozilla/standards-positions/issues/154 for some examples). It would be better to have privacy and security baked in with input from a broad group of actors (I think we can all agree that Firefox is going to be a more useful voice than Google in that sense). It's not helpful to let Google run off and write every standard themselves, with other browsers watching from the sidelines until it's sufficiently done (and unchangeable) and then having to either adopt the existing standard as-is by necessity or to refuse to support many real world web applications (for as long as that's tenable). Make no mistake - Chromium has the market share to be a workable target, and these APIs work well for developers and are genuinely useful. They will be used. There will be (in some areas there already is) a whole world of web apps using these APIs which only work in Chromium by necessity, no matter how much they'd like to support other browsers. As those get adopted by users, that's only going to drive the web further towards Chromium, until other browsers have to die or adopt the (entirely Google-written) standards themselves too to support the next generation of webapps. This is happening on desktop in some areas already. In IDEs, for example - if you buy any IoT based on Espruino, the primary dev tool only works in Chrome due to WebUSB/WebBluetooth (https://www.espruino.com/Web+IDE https://www.espruino.com/Web+IDE), while tools like Godot Editor are already talking about Chrome-only save/load support using these filesystem APIs (https://godotengine.org/article/godot-editor-running-web-browser https://godotengine.org/article/godot-editor-running-web-bro...), and I'd be extremely surprised if GitHub Codespaces and other tools aren't looking at doing the same. These are popular tools - many users want to use them, and they will have to switch to a Chromium-based browser to do so. Mobile is somewhat protected due to Safari being the only option on iPhone, but I wouldn't be surprised if the ongoing antitrust cases force them to open that up to make PWAs look like a plausible app store competitor, and the exact same thing happens there. WebExtensions is a case study of the same effect in the past. Chromium has so much weight that once they fully design and adopt an API and build an ecosystem around it, other browsers have to follow or get cut off. If Firefox & Safari had engaged with WebExtensions much earlier, they could have been driving it themselves and building consensus. Instead, they've had to copy every Google API while just tweaking around the edges. One exception, interestingly: Brave is doing some intriguing work on driving decentralization APIs for the web (native Web3, native IPFS). It's early days, but I'm hopeful that this might have the same effect in the opposite direction for those features!