I don't know about the stability/market value of this if you intend to turn this into something that attempts to make money, however. Said friend is currently using stuff like Gemini to generate HTML mini-apps as well; while he's not storing anything in databases, he's able to generate receipts and other things for essentially free.
https://github.com/JoshTheDerf/uapp
Demo apps and games: https://thederf.com/uapp/demo/
> One downside with this approach is that multiple people working on it will create different copies. To make it possible to merge different copies of the same file, each data entry has a unique UUID and timestamp.
This was the first thing that popped up in my mind: Changes stemming from two sources and reconciling them. I see that you have a statement about how to handle data entry from different sources, but I don't see exactly how those are reconciled? For instance, if two users have a copy of the .capsule and make changes, then want to share their changes with the other, you have two individual .capsules with different data.
How do you merge them?
Or at least, it's extremely limiting, compared with hosting it somewhere on the web, which is not that hard to do these days.
Think of the workflow: Any time the state changes, you need to email a new Capsule file to whoever else is using the app. And one would think the state would change at least occasionally, because otherwise there's little reason to use a DB.
Alternatively, you can just host it on the web, the DB state dynamically updates, and it's automatically available to anyone with app access. Isn't that a lot simpler?
Concurrent editing wouldn't work, though.
Isn't html/css a better distribution mechanism as most computers already have the tech to run them?
Hence 200MB applications that are complete copies of the Chromium browser to run under 1MB of actual web code.
I've experienced the same limits building small tools for myself and friends that I wanted to contain in a single HTML file without external dependencies... but I understand why the same project without these restrictions could easily become malware, and ones that could be easily propagated.
However, every browser will let you download a new version of the HTML file and save it over the old one - yes, even from a local HTML file:
const blob = new Blob(['<!DOCTYPE html>\n' +
document.documentElement.outerHTML],
{ type: 'text/html' });
const a = document.createElement('a');
a.href = URL.createObjectURL(blob);
a.download = 'mypage.html';
a.click();
Saw it on HN a few weeks back
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
I'm having Lotus Notes flashbacks.
You're gonna end up having to build a complex state sync system to a central DB anyways...
How would I know if I need this, vs something else?