Hacker News Reader

Comment by skybrian | Hacker News Reader

Under "how to save a file" [1] it tries to use window.showSaveFilePicker (which has poor browser support) and falls back on creating an invisible link and clicking on it.

It seems a bit much, versus just having a download link, possibly styling it as a button. What do you get for that?

[1] https://web.dev/patterns/files/

View on HN

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.

Good thing there's a prompt[1] then.

[1]: https://i.imgur.com/A0Byw7Q.png

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.

> When use a browser as an editor

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.

1. https://github.com/vim/vim

2. https://github.com/emacs-mirror/emacs

3. https://github.com/xi-editor/xi-editor

4. https://github.com/notepad-plus-plus/notepad-plus-plus

5. https://github.com/helix-editor/helix

I use https://www.photopea.com as a Photo editor. When working on projects, hitting CTRL+S saves the file as I expect it to do.

There are more kinds of editors than text editors, and some of them are suited to web browsers.

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.

They're assuming you generated the file in the browser and you don't have a link from a server.

It's possible to create a temporary URL (with data from an ArrayBuffer) entirely client side:

URL.createObjectURL(new Blob(...));

It creates a blob: URL that you can use as a link.

That's what they suggested as a fallback, isn't it?

More or less. You don’t necessarily have to simulate a click, though.

Right, there's now a dedicated method: `HTMLInputElement.showPicker()`.

or from a string

https://jsfiddle.net/ne0z6a7p/

Reply on news.ycombinator.com