Sarcasm:

bad bad not good. it's ok for poor people but the poor aren't capital if they produce capital (financial or cognitive or any other) without making someone else richer (in data or money) so your approach is essentially bad for the extended wall street portfolio and thus bad for the economy.

No sarcasm:

Always a good approach. Variation and customization of all kinds of tools are imperative.

The single html file approach is ok.

I did similar stuff, twice, and will transition to python, rust or zig because now freaking web hooks, sms and whatsapp notifications will be useful just because the amount and variety of tasks and active and passive participants is growing, which gave me a much better understanding of what the fuck is wrong with industries, btw (so much less than I thought). Must remember to version control, properly, though, as well as documenting and properly organizing the code, all of which is so damn 101.

it's great for everything that doesn't need writing data to disk (although some limited persistence can be had by storing data in the URL). the bummer is that even Firefox doesn't allow saving/opening .html files on mobile.

Have done this a few times. Updating the thing and keeping my data is always annoying even with web storage. The limitations of CORS also make it annoying the moment you want to do anything more involved.

In the end I usually just write a normal program for myself in autoit.

Sounds neat, I like the concept. :)

How is persistent storage handled? Do users need to be made aware that their data in local storage might disappear one day if the OS runs low on disk space?

What are the tools for and what are the tools you're replacing?

Do you have those on any public git?

Like the simplicity approach - single-file tools are underrated.

One thing to note: if you ever want "install as app" functionality, you'd need to host them (even on GitHub Pages). File:// URLs don't support service workers, which means:

- Can't properly "Add to Home Screen" as a PWA

- Can't use Cache API for offline-first functionality

- Limited to localStorage (~5MB) instead of IndexedDB

- CORS restrictions prevent fetching from external APIs/CDNs

But if your tools work fine with localStorage and file:// access, no need to overcomplicate. The current approach is valid too.