4 ms·

Browsers have existing file APIs that programmers could use but don't. To reiterate a comment from the last time this came up: > You could literally run the G

by cxr 2y ago

Browsers have existing file APIs that programmers could use but don't. To reiterate a comment from the last time this came up: > You could literally run the Golang compiler in your browser if you wanted to[...] A lot of the stuff that people think they need Chrome's proposed filesystem APIs for are not actually things they need. <https://news.ycombinator.com/item?id=41176674 https://news.ycombinator.com/item?id=41176674>

PittleyDunkin 2y ago
Ok but that outlines a miserable user experience.
- deleted 2y ago
  [deleted]
porridgeraisin 2y ago
Can't imagine a worse alternative. The filesystem api is really good. For example, I use the google office suite entirely offline through the official extension that uses the filesystem api. You can edit a local file just like that. Same goes for photopea. You can't seriously suggest manual save as an alternative. Ctrl+S, choose file, do you want to overwrite, yes. That's way too much friction, come on.
jitl 2y ago
Literally no one wants to work like this. A save dialog every time I press cmd-s? If we shipped local file editing for Notion that worked like this our users would egg our office. For any app outside maybe like an image macro meme generator this sucks. For anything else like for example a notes app, photo library, more serious image editor, PowerPoint, video editor, animation software, anything people spend >1 hour a day in - you want to auto save, and often you want to manage a tree of files in a root folder as a “library” of the users’ data. Electron only exists because browsers are too limited. That’s all electron is anyways, a browser with much better APIs for writing apps then the ones included in Chrome and especially Firefox.
- cxr 2y ago
  Geez, you fucking people... An API is not by definition fine-grained control over UI/UX. Browser makers can implement the new file system API with better UX than what they have now. They can also do that with the existing file APIs; there's no contract involving the existing APIs that says things have to work the way they do right now. (They could also implement the new APIs in a way that technically works but has just as shitty or worse UX than the existing ones.) If you want good/better UX for file save operations, then lobby for that. A whole new (sprawling, bad) set of APIs for giving websites access to the user's filesystem is an orthogonal matter. You're conflating two separate things.
  - jitl 2y ago
    I do not want better UX to read and write a single file. None of the example apps I mentioned work well with R/W to a single file except maybe the image editor example. I want permission to create, read, write, move/rename files and directories within a root directory selected by the user. Anything less is not sufficient for AAA quality local-first apps. I think window.showDirectoryPicker() is fine. I hope Firefox will implement this or a similar API, but I am also okay with launching major features without Firefox support. I have done so before to no discernable adverse effects. https://developer.mozilla.org/en-US/docs/Web/API/Window/showDirectoryPicker https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
    - cxr 2y ago
      Nothing I just said is limited to the narrow use case of dealing with single files. If you want improvements for multiple files, then congratulations, you can have that, too! > I want permission to [...] move/rename files [...] Anything less is not sufficient for AAA quality local-first apps. And robbers want to be able to slip their fingers into the wallets of whomever they want. So? Very few apps outside of file managers actually need to be able to move and rename the user's files, and it would be much better if they those that don't would assume they aren't going to be able to. You can call this a prereq for high-quality apps, and I'll maintain my view that apps that refuse to work unless you grant an overbroad set of capabilities that they don't really need are ipso facto low-quality. Besides, if you actually want all this, then you can build an app for remoteStorage.io right now, without needing to know whether the files live on the user's disk or not—and if the user wants the storage area they connect to your app to to be backed by local files, then that's a choice that they can make. Your app doesn't need to be able to discriminate between whether they are or they aren't.

by cxr 2y ago

PittleyDunkin 2y ago

Ok but that outlines a miserable user experience.

deleted 2y ago
[deleted]

porridgeraisin 2y ago

Can't imagine a worse alternative. The filesystem api is really good. For example, I use the google office suite entirely offline through the official extension that uses the filesystem api. You can edit a local file just like that. Same goes for photopea. You can't seriously suggest manual save as an alternative. Ctrl+S, choose file, do you want to overwrite, yes. That's way too much friction, come on.

jitl 2y ago

Literally no one wants to work like this. A save dialog every time I press cmd-s? If we shipped local file editing for Notion that worked like this our users would egg our office. For any app outside maybe like an image macro meme generator this sucks. For anything else like for example a notes app, photo library, more serious image editor, PowerPoint, video editor, animation software, anything people spend >1 hour a day in - you want to auto save, and often you want to manage a tree of files in a root folder as a “library” of the users’ data. Electron only exists because browsers are too limited. That’s all electron is anyways, a browser with much better APIs for writing apps then the ones included in Chrome and especially Firefox.

cxr 2y ago
Geez, you fucking people... An API is not by definition fine-grained control over UI/UX. Browser makers can implement the new file system API with better UX than what they have now. They can also do that with the existing file APIs; there's no contract involving the existing APIs that says things have to work the way they do right now. (They could also implement the new APIs in a way that technically works but has just as shitty or worse UX than the existing ones.) If you want good/better UX for file save operations, then lobby for that. A whole new (sprawling, bad) set of APIs for giving websites access to the user's filesystem is an orthogonal matter. You're conflating two separate things.
- jitl 2y ago
  I do not want better UX to read and write a single file. None of the example apps I mentioned work well with R/W to a single file except maybe the image editor example. I want permission to create, read, write, move/rename files and directories within a root directory selected by the user. Anything less is not sufficient for AAA quality local-first apps. I think window.showDirectoryPicker() is fine. I hope Firefox will implement this or a similar API, but I am also okay with launching major features without Firefox support. I have done so before to no discernable adverse effects. https://developer.mozilla.org/en-US/docs/Web/API/Window/showDirectoryPicker https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
  - cxr 2y ago
    Nothing I just said is limited to the narrow use case of dealing with single files. If you want improvements for multiple files, then congratulations, you can have that, too! > I want permission to [...] move/rename files [...] Anything less is not sufficient for AAA quality local-first apps. And robbers want to be able to slip their fingers into the wallets of whomever they want. So? Very few apps outside of file managers actually need to be able to move and rename the user's files, and it would be much better if they those that don't would assume they aren't going to be able to. You can call this a prereq for high-quality apps, and I'll maintain my view that apps that refuse to work unless you grant an overbroad set of capabilities that they don't really need are ipso facto low-quality. Besides, if you actually want all this, then you can build an app for remoteStorage.io right now, without needing to know whether the files live on the user's disk or not—and if the user wants the storage area they connect to your app to to be backed by local files, then that's a choice that they can make. Your app doesn't need to be able to discriminate between whether they are or they aren't.