The advantage of using the `showSaveFilePicker()` method is that you can get a `FileSystemFileHandle`, with which you can then implement a true "edit, save, edit, save,…" flow; always saving over the current file, instead of downloading copies on each "save".
In the future you may even be able to save the handle and retain permission to the file or directory between page reloads or even browser restart. I've been experimenting with this in Chromium. There's a preliminary implementation behind a flag (--enable-features=kFileSystemAccessPersistentPermissions).
The preliminary implementation is still buggy, but it's an extremely useful feature. You could use it to e.g. make a web version of VSCode that only ever has to request your permission once, and can then edit any file in your workspace directory without spamming you with more permission requests, just like the Electron version of VSCode. (The persistent file access permission is displayed in the address bar and can be revoked at any time).
And getting the default permission period right for this feature once unflagged is something we're very actively discussing. Watch our publications web.dev and developer.chrome.com for updates on this.
As a user, I think that's a very unexpected feature. When a file crosses the border from browser to file system, I expect it to remain untouched. This approach feels very unnatural to me.
As a user, I think that it is a very expected feature. When use a browser as an editor, I expect it to change the file when I save it. This approach feels very natural to me.
thats the problem. You should never be doing that. You should be using an editor, as an editor. The confusion is understandable though, as in general editors [1] aren't [2] widely [3] available [4] for [5] people to use.
Yeah, there's some really dumb practices out there. Some people even exclusively run their editor inside an EMULATOR of one of these devices: https://i.imgur.com/SBUxWMg.jpg - rather than using their actual operating system.
