Cool project, though - don't mean to take away anything from it.
I find the totally self-contained nature of them very appealing because it travels well through space and time, and it's incredibly accessible, both online and offline.
My current side project is actually using a WebDAV server to host a wide variety of different single HTML file apps that you can carry around on a USB drive or host on the web. The main trick to these apps is the same trick that TiddlyWiki uses, which is to construct a file in such a way that it can create an updated copy of itself and save it back to the server.
I'm attracted to this approach because it's a way to use relatively modern technologies in a way that is independent from giant corporations that want to hoover up all my data, while also being easy to hack and modify to suit my needs on a day-to-day basis.
- Split JS out from HTML, split CSS out from HTML
- Keep files reasonably small
So if I read "Single HTML file" I'd expect around a couple hundred lines at most, possibly with some embedded CSS.
It's kind of like saying "I've solved your problem in one line of JS" but then your line of JS is 1000 characters long and is actually 50 statements separated by semicolons. Yes, technically you're not lying, but I was expecting when you said "one line of JS" that it would be roughly the size and shape of a typical line of JS found in the wild.
Most projects prefer to have a separate database, server side rendering and often even multiple layers of compilers too.
A lot of projects even require hundreds of megabytes of language runtime in addition to the browser stack.
So a single HTML file is still unusual even if it’s something nearly any web app could technically do if they wished.
And for this reason alone, I think it’s unreasonable to have expectations of a JavaScript-less, CSS-less code-golfed HTML file. This isn’t sold as a product of the demo scene (that’s another expectation entirely). This is sold as a practical self-hosting alternative for people who need a kanban quickly and painlessly. Your comment even proves that it works exactly as that kind of solution. So having inlined JS is a feature I’d expect from this rather than complain about.
When I see “single HTML file” it conjures up the same expectations as when PocketBase[0] describes itself as an “Open Source backend in 1 file”.
That is that I can copy that file (and nothing else) somewhere and open/run it, and the application will function correctly. No internet connection, no external "assets" needed, and definitely no server.
This mode of distribution, along with offline and local-first software, avoiding susbscriptions and third party / cloud dependencies, etc. all appeal to me very much.
So far I'm impressed, I appreciate the nice, dense and uncluttered UI out of the box and it seems to cover enough functionality to be useful. I'll definitely look out for a chance to give it a spin on something real.
[0] which I also think is great
The two projects out in the wild that natively work with this approach are TiddlyWiki and FeatherWiki.
I see room for a lightweight version of a calendar, a world clock, and even a lightweight spreadsheet that could be useful. I also have an idea for something I call a link trap where you can rapidly just drop links in and then search and sort over them to quickly retrieve something you saw before that was interesting. Sort of like my bookmarks-outside-the-browser except more of a history-outside-the-browser.
Edit: I sketched out a basic version in JS + Python, it's fairly ok to use. The nice parts about this approach is the HTML files are viewable without any extra services, and the service that enables saving doesn't itself need configuration or to keep state.
Yes, they could be. And then they would have the same super power is this file: you can put it on a flash drive and run it anywhere with no setup or installation.
We are definitely coming at this from a different angle.
Sorry if it's a bit direct and unrelated. I've actually got a question if you wouldn't mind.
I've been in the process of creating a local-first, non-subscription based Linux/Windows application that acts as a completely local search engine for your own documents and files. It's completely offline, utlises open source LLMs and you just use it like a search, so for example "what's my home insurance policy number", "how much did I pay for the humidifier", that kinda stuff. Things where you don't know exactly where the file is, but you know what you're looking for. You can browse through the results and go direct to the document if you want, or wait for the LLM response (which can be disabled if you just want plain search) to sift through the sources and give you a verifiable answer (checks sources for matching words, links to the source directly for you to reference etc).
My question would be. If you wanted something like this, how much would you pay? I'm going with the complete ownership type model, you pay, you get the exe and that's that. You like the new features in next major release, you pay an upgrade fee or something like that, but it's a "one and done" type affair.
$10, $30, $60, $100? I want it to be accessible to many people that don't want to feed their data to big corps but I also want to be able to make a living off improving it and bringing these features to people.
I've not really worked out any of this monetary side of things, or if it's something people even want. It's something I've developed over time for myself which I think could potentially be useful to other people.
The downside is even though you know the current directory due to window.location the API is written in the way it assumes you either want a default location like "desktop" or need the user to navigate to the directory before you can do operations on it (for security reasons) even from a local context. The user needs to select the directory once per fresh page load (if you've dynamically reloaded the current content then multiple saves need only prompt once so long as you save the handle).
The number of clicks is an implementation detail. It depends on whether or not you're using the web file API, some browser download capability, a browser plug-in, a mobile app, desktop app, a webdav server, or something else.
For people trying it for the first time, they often have the experience you're describing. But for most anybody that actually picks this up and uses it on a day-to-day basis, they use something else that saves transparently and automatically.
All of this is orthogonal to whether or not it's in a single HTML file. I fear you took lelandbatey's original ctrl-s reference a bit more literally than intended, though if you want to be pedantic, I can confirm I use applications in this style all day as part of my daily workflow and I do press ctrl-s and it saves with no further interaction in fully patched versions of Chrome, Firefox, and Safari with no plugins whatsoever.
Any additional info/pointers on this ?
I try to avoid proprietary software when I can, so if I wanted something like this I’d definitely look for open source options first. I’ll endure a reasonable amount of setup pain as long as the solution is what I’m after to go the open source route over a proprietary app.
For example, your idea seems to sit somewhere between Alfred (which I’ve bought every upgrade/ultimate pack/whatever for) or Raycast, and an LLM augmented search of a NAS / “personal cloud” server. So assuming I wanted it, if there was no neat and self contained open source solution, I’d probably try to cobble something together with Alfred, Ollama, Open WebUI, etc. (all of which I already run) plus some scripts/code first, too.
That said, for a good, feature-full local/self hosted solution that does exactly what I want in the absence of an open source option (or if it’s just much better in significant ways), I’m generally willing pay between $20–$100 per major release (for ex. I pay around that for e.g.: Alfred, the Affinity apps). For this I suppose $30–50 if it was pretty slick and filled an important niche. (I have paid more a handful of times in my life, usually for very specific use cases or if it helps me professionally, but not very recently.)
However, if a nice (or very promising and exciting to me), well maintained open source (GPL/MIT/Apache/BSD type license) solution does [most of] what I want and it’s something I really use (and a smaller project[0]) then I donate $10–30 per month (ex.: Helix, WezTerm). I sometimes do smaller or one-off donations, etc. for stuff I use less but appreciate.
That is, I intentionally pay more for open source I care about, and would humbly suggest considering that option for your project. Though I recognise that sustaining yourself financially that way is more than likely considerably harder, even with my small personal attempt at creating incentives for the world I want to see :)
NB: I do not buy subscription software unless it comes with a genuinely value added service (storing a few MiB on the devs cloud service doesn’t count) or access to data, for instance detailed snow/weather forecasts, market data, an advanced AI model (though my admittedly relatively minimal LLM use is currently >95% local and free/“open source” models).
[0] I don’t give money to the Linux kernel devs, etc. as I don’t think it’s likely to has as much positive impact
(And I am not the one downvoting you, in fact I couldn't even.)
As an aside: I do find these applications very interesting and am considering to make use of Nullboard myself, but also am weighing it against simply using org mode in Emacs and am looking for any advantage it might offer. Of course the ctrl+s issue plays a role there as well.
Is there some way to accomplish this through GitHub? Like the single html file running on GitHub.io pages can commit the changes to its repo?
My primary saver is a Python script that I wrote called Notedeck, but I also sometimes use a Rust webdav server called dufs.
I haven't released either of my projects I'm working on that are the client files, otherwise I would have just linked them.
For the benefit of the Hacker News audience that are curious, let me take a stab here.
The general strategy is to include JavaScript in the HTML document that knows how to look at various nodes in the DOM and create a new version of the document that uses an updated set of data.
Some sections of the data can be pulled verbatim. So, for example, if you have one giant script at the bottom of the doc, you can give it an ID of perhaps S, and then use that ID to retrieve the outer HTML of that script tag and insert it into the clone.
Other areas of the DOM need to be templated. So for example, I insert a script that is of type JSON, and that contains all of the data for the application. This can be pulled and stringified when creating the clone.
For a minority of attributes like the title and document settings like whether or not you're in light or dark mode, you want to avoid a flash of unstyled content and so you actually templatize those elements so they are written into the cloned copy with the updated data directly inline.
There's no real magic to it, but it can be a little bit tedious. One really interesting gotcha is that the script tag is parsed with higher precedence than quote tags. And so I have to break up all script tags that appear in any string that I'm manipulating so that the parser does not close out the script I'm writing.
I have a very minimal app that uses this technique called Dextral. I'll be happy to host it on my site and link it here.
It’s one reason Mac Apps get bundled as a single “file” from the user perspective. You don’t have to “install”, you just copy one file with everything. It’s a simpler dev experience.
Sure there are tradeoffs, but that’s great! We should accept that tradeoffs mean people can chose what works best for their specific context, rather than “best practices” which are silly.
Not heard of Alfred as I'm not in the Apple ecosystem, but yes, you've hit the nail on the head between the combination of both after doing a bit of digging.
I'll seriously think about making it open source (time to brush up on the different licenses again). I want to keep it accessible so even my grandma could use it. I'm not expecting her to go cloning a git repo and checking dependencies etc, so I'm packaging it into a standalone executable. Maybe making the source open is something for me to consider and people can just pay if they don't want to go through any setup hassle (do I put some soft donation paywall up with a $0 minimum or something - just thinking out loud).
In terms of pricing, you've landed where I was thinking, maybe more towards the $30 end. I mean I think it's pretty slick and fills a niche, but I'm conscious I may be ever so slightly biased. A lot of stuff to mull over. Thanks again, really useful.
https://developer.chrome.com/docs/capabilities/web-apis/file...
It will greatly increase the attractiveness of your software to me if you stick to the philosophy you’ve outlined there.
One approach that I’ve seen and have absolutely no issues with (in fact I think it’s a pretty smart way of doing things) is where a fully open source project provides code and releases on GitHub and in package managers like Homebrew, but also publishes releases as paid software on app stores.
This allows users to pay for the peace of mind of a “verified” app store install that Just Works. It also provides an easy way for the more technical among us to donate. I’ve switched to paid releases like this myself for a least a couple of fully open source projects just to give a little back.
That's not to say one couldn't still do what you're describing via other headers, I'm just saying "<input name=username><input name=password>" won't get it done