[mg]

Now that Chromium supports the File System Access API on desktop and mobile, I am building every software I need as HTML+JS+CSS.

Before that, handling files in the browser was cumbersome. You had to offer download and upload links for users to manage files. And handling whole directories was impossible.

But now web apps are like native software tools that you can use to edit and manage files on the file system.

And the bonus point is that what you build this way is fully functional on mobile too. Right away, without any changes. At least on Android.

[Mars008]

What about FireFox, does/will it support file system access? I'm not an expert, just thinking this way and don't like Chromium. The idea is to use light web server in application + browser with JS. This makes it easier and more convenient as it can naturally run remote, on microprocessor. Also LLMs are good at generating such UIs.

[rpdillon]

This is how I develop all the software that I don't work on professionally. I have a variety of small web servers with various capabilities that I use. The latest is Copy Party, which I learned about from HN a couple of weeks ago. My apps are then single files that know how to write modified copies of themselves back to the server. The server is dumb, it doesn't really know that it's anything other than just a file upload. I then use SyncThing to replicate that folder structure across all my devices so I have offline access by default.

[theshrike79]

Copyparty[0] is amazing. I've noticed copyparty+webdav is a lot faster for browsing my NAS than smb or nfs from macOS.

I've been meaning to build a gallery application (or simple web page) that can browse pictures from a copyparty instance and sort/organise them with an UI fit for my purpose.

Any pointers how I could make one that self-saves to copyparty?

[0] https://github.com/9001/copyparty/

[rpdillon]

Sorry for taking so long to respond...I was out on vacation!

The general strategy is to figure out what state needs to be stored in your app, and combine that into one div in the page that can be grabbed via something like innerHTML. For a gallery app that is viewing pictures on copyparty, that will be the metadata, like the URL of the image, the tags you want to apply and/or what category it is in, the index within the album, the date info, etc.

Then, when your page loads, you can load all that and reason about how to arrange your photos, what to display, etc. Once that's done, the URLs can be swapped in to generate the appropriate view. I would give some thought to how to leverage WebDAV to create a directory that can store e.g. thumbnails. Copyparty does that itself, but your app should likely have its own disk-based cache accessible from a folder served by Copyparty.

The self-save part is mostly creating a something like a clone function that knows how to clone the static parts and inject updated sections for the data. I've written a little about about how to do this in my post years ago about a TiddlyWiki saver written for jart's Cosmopolitan.

https://rpdillon.net/redbean-tiddlywiki-saver.html

I've iterated on it quite a bit since then, and haven't updated my site accordingly. It's probably worth documenting the progress I've made since.

[8organicbits]

https://caniuse.com/native-filesystem-api

Looks like Firefox does not support it currently.

[jazzypants]

It's even worse than that. If you click on the resources section, you can see that Mozilla considers the proposal harmful[1]. They say there's a subset of features that they may consider. Safari seems to be in the same boat, but I can't find an official standards position.

[1] https://github.com/mozilla/standards-positions/issues/154

[h4ch1]

I have been evaluating and testing the Filesystem API for a local first web based CAD editor and having direct r/w access to the filesystem is a great way to make such a thing, couple with the FilesystemObserver[1] API this makes building proper editors on the web a breeze.

In place of this, Firefox recommends using the origin private file system (OPFS)[2] which is basically a sandboxed filesystem that the users cannot access. Though I agree from a security perspective it kind of makes sense (not particularly for my usecase), but it removes the ability for the user to have realtime changes on local files.

An example of this is using the web based tool as an intermediary step or a processing step in a bigger pipeline; I save it using my web tool and then native applications automatically handle file updates. This just creates an extra step for Firefox/Safari to replicate changes locally by having to manually update local files.

Also neither Firefox nor Safari support showDirectoryPicker() which also creates blocks for building a web based editor.

I love Firefox and I hope they can add support for this. I have stopped caring about Safari/Webkit completely because it's hellish to try and maintain feature parity while NOT sacrificing innovation and ease of use.

[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystemO...

[2] https://developer.mozilla.org/en-US/docs/Web/API/File_System...

[lyu07282]

+1 Another bonus is that it's properly sandboxed, you only give access to the files/directories and other resources it needs.

[robertoandred]

Except you lose native document UI features. Especially frustrating in Electron "apps".