One or two years before, I would have agreed with the HTML approach, because I would have wanted it to be easily accessible from mobile and what not. But now, I just prefer having a full computer with me (and planning to invest in a smaller and more portable one). A browser is a very wasteful and limited interface.
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.
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.
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?
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.
I really love it.
In this year i tried make some note with html
I also posted in hn (https://news.ycombinator.com/item?id=43358914)
I think if the browser provides more nice file saving solution the standalone html app will be more powerfull
These? https://github.com/ajtracysk and https://medium.com/@ajtracysk
I just use Emacs.
One or two years before, I would have agreed with the HTML approach, because I would have wanted it to be easily accessible from mobile and what not. But now, I just prefer having a full computer with me (and planning to invest in a smaller and more portable one). A browser is a very wasteful and limited interface.
I've built a few, sometimes for fun and sometimes as tools.
There was a recent submission with some good examples: https://news.ycombinator.com/item?id=46223882
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.
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?
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.
Web storage API days hi:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...