[replete]

You can do a lot of things by dragging folders onto file inputs, but it is somewhat rubbish for user experience with the friction of getting files in and out of your app. Obviously it depends on what you want to do, but it seems a limiting factor. Allowing HTML application permanent permissions to file system without user input makes apps a lot more useful and portable.

Recently. I wanted to organize around a thousand short videos. I looked into software and the solutions were really integrated, media library etc. MacOS has tagging in the filesystem, but that ties me to an operating system, and didn't give me the explore related function. I wanted something that could let me browser a folder with added metadata, explore related clips etc.

After looking at all the options I could find, I realized it was easier to just build myself a little Node.JS app using sqlite for metadata, it worked great. I plugged in local ollama and whisper for transcriptions and automatic tagging, which worked suprisingly well. It's annoying needing to run a server for such a simple app, packaging it is just so heavy ... and I thought, it's really not that far off being something I could do in a single HTML file, it was pretty much just the filesystem access - then my app/content is just a folder that does what I want to on any platform without installations or configuration.

Thanks for linking the Joe Armstrong lecture, I've watched half and its wonderful.

[cxr]

> it is somewhat rubbish for user experience with the friction of getting files in and out of your app

It's not worse, generally, than the average experience of using a NodeJS program that won't run because the dependencies didn't install correctly or it's the wrong version of the runtime, or... (cf Armstrong; or, to borrow a saying by Ousterhout (with a small tweak): the greatest improvement to a program of all is when it goes from not-working to working).

The two worst rough edges for file saving for browser-based apps are:

- if you consider, say, a paint program that you're using to work on an image, it can't implement the ordinary save behavior where some keyboard shortcut or menu items saves (overwrites) the current file you're working on; to do the same in the browser requires the user to do the equivalent of a Save As every time (instead of a Save)—i.e. complete with a prompt to double check that the user really wants to overwrite the previous file

- some browsers have changed the default download behavior so it automatically saves to a downloads directory without asking the user and allowing them to change the path/filename with a conventional filepicker; this setting has to be changed by the user themselves to get the old, circa 2005 browser download behavior

These are both issues that can be fixed and don't require something as expansive as Chrome's filesystem API proposal.

re alternative options to your NodeJS-powered video tagging application server: check out <https://redbean.dev/>

[replete]

I agree, file access via upload/download concept is friction on the user experience. I'd love to see serverless offline HTML applications with permission based file system access, because you can do so much very quickly in the browser with access to GPU, bluetooth, USB even, but I'm not holding my breath because of the security implications

Redbean looks good, I didn't know about the APE format, but unfortunately doesn't solve the file system access problem without presumably rewriting a backend in Lua. Docker, reluctantly, is better than nothing.

[cxr]

I suspect Justine will eventually do what the Cloudflare Workers team did, which is after having originally only supported Lua, to start supporting JS (albeit via quickjs in the redbean case, rather than V8) and then see wild uptake.