For people who are confused: Hyperclay is a NodeJS server and frontend JS library that allows HTML pages to update their DOM and then replace their own .html source with the updated version.
Imagine clicking a checkbox, which adds the `checked` attribute to its element, then using Hyperclay to globally persist this version of `document.body.outerHTML`, so that it's there next time someone visits the page. There's automatic versioning and read/write permissioning.
It's a pretty cool project! I'll definitely try for my own personal tools.
Do note that, from my understanding, it's most useful when there's one developer who is also the only content editor. Otherwise you'll have editors overwriting each other's changes, and if there are multiple copies there's no easy for the developer to push a change to all copies.
I love this, I think this brings "block editing" capabilities to the masses, which is a big selling point for WordPress. In recent months, I've been looking at micro-sites and I concluded that Carrd is king for this type of landing pages/microsites. So this looks very promising for this respect. Either of you care to share or dispel security concerns or describe attack surface? For the past 6 months I've been looking at HUGO sites and the simplest deployment approach I found was alpine/sqlite/hugo containers at 5-10mb in size. Is there a way to delegate control/editing of sections/pages? I think the world needs a simple platform to build sites and delegates sections to respective departments/units. The only platform which seems solid for this is drupal, but it's kind of overkill for SMB orgs.
Thanks. Author mentioned TiddlyWiki as inspiration. But the whole point of TiddlyWiki was that it doesn't need a server right?
So I'm trying to understand the difference, the payoff. I understand that local web APIs are ass and you very quickly run into the need for a server.
But I'm wondering about the utility of combining the two approaches. It seems like a contradiction in terms. Here's a server to help you with your dev setup oriented around not needing a server.
I guess the main win would be cross device access? You have it online and you can edit it easily.
I'm editing my stuff on my phone in a text editor. And syncing it to my laptop with a sync app.
Turns out, the original TiddlyWiki used a java jar to handle the file persistence. (I remember it being so magically automatic, but recently investigated how it was done)
I see, so you make edits, the Javascript edits the html, therefore File -> Save Page will download an html file with your changes in it that you can open again.
I forget that File -> Save is even a thing for websites.
TiddlyWiki can replicate itself. All users can freely edit any TiddlyWiki and save their changes to their filesystem. There's a few options for exports.
It is a common gotcha that new users will lose some of their work while they learn persistence.
They never did, if anything it's the opposite in that I think there are now APIs that can make this possible.
With TiddlyWiki you had to essentially File -> Save As and save the HTML back over itself. There were other ways too but they were all workarounds to the issue that browsers don't allow direct access.
They did back around 2008. I used Wiki on a stick - see https://stickwiki.sourceforge.net/which was kind of neat) but after a few years, Chrome etc stopped letting it save itself.
Thanks for the description, I kept reading the webpage and didn't understand what the project was or how it worked. Yours is really succinct and clear.
To be completely honest, I don't see how this is more useful than adding a sync layer to localStorage. I did make a service that does that at htmlsync.io and am genuinely curious how this solution is better.
Your notes are the HTML file! You can keep it in your documents folder, sync it via any service, track it in version control, etc. It’s for folks who know what the filesystem is, don’t know how to host a server (or don’t want to), but want a website-like experience. Works offline, too!
I finally also recalled this project (tiddlywiki), but CMIIW, the statefulness of the hyperclay is only for developers, the end user will get the same conventional html. Without some kind of common solution/protocol/standard on the browser side that would allow persistence it's not so exciting. Theoretically there might be some kind of simple protocol that would save html file versions on the server based on the cookie, but there are so many ways this can go wrong
The file itself provides both the dynamic functionality and data storage, but you need an engine (like obsidian) to make the data persistence and dynamic parts work together. I.e. if there is a button that adds a task to a todo app, your engine modifies the HTML file with the new content.
I think contenteditable is more akin to a rich-text document, while Hyperclay goes a bit beyond by allowing JS to edit the DOM too. I think Smalltalk images and virtual machines are a closer comparison, but applied to the web. You download the image, with some running code, use it, and persist the whole application state.
No, this need a server too. Everything that saves changes to non local (shareable) locations needs some kind of a server. The best solutions are of course when OP hosts the server and you pay for it /s
Wiki has specific content you can add. New article, body of an article, etc. This lets you change all the html. With this, you could edit your wiki into a calculator.
I would like web standards have better support for pages stored in a local file (opened using file:// protocol). Sometimes I write simple HTML/Vue based mini-apps for myself and every time something doesn't work and I need workarounds, for example:
- local HTML file cannot import local JS modules, so I have to use legacy writing style
- local HTML file cannot open other local files (for example, audio files)
I understand that there is a risk if we allow local HTML files to access anything, but there should be some way - for example, a file or directory might have some suffix that allows access to it.
I do not want to use a web-server because it feels like overengineering and I don't want to open a terminal, navigate to a directory and start a server every time, it takes too much time. I just want to type the URL and have my app running.
> I understand that there is a risk if we allow local HTML files to access anything, but there should be some way - for example, a file or directory might have some suffix that allows access to it.
> I do not want to use a web-server because it feels like overengineering and I don't want to open a terminal, navigate to a directory and start a server every time, it takes too much time. I just want to type the URL and have my app running
I'd love for there to be an "offline only" mode for browsers where you can either access the local filesystem or remote pages, but not both. I don't think this would completely solve the use case you describe, since there would still presumably be circumstances where it would be helpful to reference something external, but it feels like it would be pretty useful to be able to use a browser as a limited server for static files, and it would be relative simple and intuitive compared to needing to have something in the files themselves indicate the intended semantics.
A significant hindrance for generator-type apps is that only pages loaded via HTTPS have access to the clipboard API, so ”copy to clipboard” does not work via file:///.
You can have a zero-build zero-dependency offline-only app which users could theoretically just save as a page, but copy buttons will not work, so you have to detect the API not being available and replace buttons with popover textareas. Clunky.
As for running a local server, VS Code devcontainers are the solution. Open your workspace, it runs the devcontainer, and you have a server up without extra hassle. Add a command to generate certs and you can have HTTPS locally.
This is so weird that a random website on a random server (having SSL doesn’t change that in the slightest) is considered less of a risk than a file I have on my own computer.
The rule was probably intended to block public non-SSL pages, so your clipboard data doesn't ever get sent over the wire unencrypted.
Why does it block local pages? Well what benefit of is to Apple or Google if it were easier to make good localhost webapps?
Try deleting Safari site data(indexed DB etc) for your localhost site. You won't be able to. Hell, even deleting data for a specific public site is hilariously painful. Try adding a certificate authority to your iPhone. Try playing locally cached audio blobs via web APIs on an iPhone. There's probably 1000 more.
The random website cannot access arbitrary files on your computer's file system and send it somewhere else. An html file with javascript running locally, if trusted, on a typical personal computer could do that.
There should be some way to mark files as accessible, for example, place them into a folder with a specific name (like "html-accessible-files") on the same level as HTML file.
> As for running a local server, VS Code devcontainers are the solution. Open your workspace, it runs the devcontainer, and you have a server up without extra hassle
it's not easy to install VS Code, let alone use it. VS Codium (and VS Code) are Electron apps, and it is difficult to sandbox them, as Electron (and Chromium as well) use suid helper - a priviledged binary that launches as root, and I won't allow suid binaries in a sandbox. Also, it requires GPU access for fast rendering, and it is difficult to provide in a safe way or switch to software rendering (I couldn't figure it out). Electron apps are a pain to install.
One could use a virtual machine, but it would use more resources.
Obviously, that's not VS Code's issue, it is a problem with Linux which doesn't come with a good sandbox.
It is much easier to type python -m http.server to launch a server, but you need to open a terminal and navigate to a directory first, that takes lot of time I would rather spend on something different (like figuring out how to work around issues with suid binary in Electron apps). And this looks like a hacky workaround, launching a web server only to gain more privileges in a browser.
It does, given that I don't always remember the path to the app. Also, on my Linux system the terminal doesn't remember windows and tabs and I have to open them all manually after reboot (I could ask ChatGPT to write a script for that but it would be easier if I hadn't to).
Maybe you can associate html files with or use open with to pass them into a script that calls python -m http.server and creates and opens a url to the file via the python server in the browser.
Windows used to have HTA applications, html files with a different extension that opened in a browser without menus and had access to filesystem APIs over javascript (jscript). It was probably a security nightmare, but I could see a modern version of that built on electron. Access to a folder and a sqlite db would be enough.
There's also Orca for building sandboxed wasm apps but it removes the browser and the Dom and only gives you a canvas to work with.
I was annoyed too when they started to close off HTML as a local platform.
But! it is still very open (you complain about audio and javascript but they both work) also I've figured that it isn't really much of a problem to start a python/node webserver for the things I'm not allowed to do. Literally a fraction of a second. Just set up a "webserver_here" command in your terminal, or keep one running constantly. Also I'm starting to fear local HTML more and more, I'd actually be happier with a much stricter boundary.
This is quite similar to what I was trying to explore with [1] & [2] yesterday.
Currently, the only option I found is to use localStorage and give the user the option to manually export and import.
Hyperclay has given me some ideas. What I want is something like [3] but that the user only needs to install once. One electron app that can load our mini-apps.
I had the same problem, regarding localStorage synchronization. For that I made htmlsync.io, but only really worth it for people who have many local apps like that and really need the localStorage sync.
Thanks! Pretty much, yes. Also if you are a dev and just don't want to spin up a server for every simple app you vibe code, you could find this useful.
To be honest, I wanted this for myself and felt guilty not making something more serious out of it since I liked the idea.
I have been using python http server to get this working. Go to a place where you have your index.html, start a python server, python3 -m http.server, and voila, everything is now importable and locally accessible.
It's been a while, but if I remember correctly you can't use some <canvas>/WEBGL features on images that are loaded from file:// URLs because of CORS (I think it was off-screen canvas). The only workaround I found was to embed the images inside the HTML using base64.
I appreciate the storytelling and the nice graphics, but after reading 10 screen lengths of this story I still don't understand what technology they are using to achieve this.
Is it a lot of words to talk about localstorage? How exactly are the changes persisted to the HTML file? Is it using FileSystemAPI to overwrite the previous HTML file? How can they implement it seamless for the user without them having to choose the proper file in the "Save As.." dialog?
1. Hosted: You get a bunch of "HTML Apps" that persist themselves by calling their own /save endpoint. We grab the HTML and overwrite their-app-name.html, making a backup/version along the way. (Each user can edit their own app only, but they can also enable signups so that other people can fork their app. We also have plans to allow them to ship optional updates to forked apps.)
2. Local: You download the open-source Hyperclay Local [0] and you can have your own personal, local HTML apps that also call the /save endpoint and make backups. You're also open to extracting the core code from this to host your own personally malleable apps on your own server (just implement some kind of auth)
Sounds like modern version which replaces FTP access with nodejs server. But you have to host it on a server or pay monthly fee anyway so you do need a server. AKA ad for OPs business.
I'm also a bit lost after scrolling through it. It seems if we take this one step further and add a bit of syntax to HTML to be executed on the server you'll have invented PHP / WordPress right?
AFAICT this is another cycle of; a decent system becoming overcomplicated because someone wanted to make it multi-tenant, and the re-discovery that 90% of the "improvements/advancements" are essentially bloat in the context & freedom you find/create.
> It would be a great to ignore all the noise of modern web dev and just build the experience I want
sandwiched in between meme images that intersperse short bursts of text as if the reader needs constant distraction from the act of reading.
The experience I want is a short prose description up front, backstory that flows, and diagrams only where they actually illustrate a concept that needs it.
There's a DB on the server. It's just storing HTML with all its views instead of storing JSON, an extract of the information that is allowed to change...
This is coming close to WWW's original vision because the very first web browser was also an editor. Tim Berners-Lee's application on the NeXT was basically a wrapper for the operating system's built-in rich text editing class named TextView. (It later became NSTextView on Apple's Mac OS X and still powers the TextEdit app on Mac.)
We lost editing for two reasons:
1) The HTTP PUT method didn't exist yet, so edited HTML files could only be saved locally.
2) Mosaic built a cross-platform web browser that defined what the WWW was for 99% of users, and they didn't include editing because that would have been too complex to build from scratch in their multi-platform code base.
Making a more read/annotate/write web is near and dear to my heart. There's a lot I find admirable - noble about pages like Hyperclay!
But also, it's a distinctly different answer for each page to build its own toolkit for the user (Hyperclay) vs TBL's read-write web. The user-agent ought, imo, afford standard tools that are going to work across web pages, that extend the user agency whatever site they are visiting.
Yes, I agree. My dream would be to one day work on a browser and integrate Hyperclay into it. I believe web apps have been around long enough as a core web technology that browsers should ship with a local web host, knowledge of what a user and user account is, and the ability to persist to disk whatever the user chooses.
If you were to have an accepted w3c proposal and working implementation in local browser forks, you could potentially chat with the browser teams to add the experimental feature first through a flag users would manually have to turn on, and then later potentially it could get integrated.
I think the scale difference is the whole point. Wikipedia has billions of active users, while these Hyperclay-style persistent documents have only a few.
Saying "we don't need this because Wikipedia already solved it" is kind of like saying in 1976: "Nobody needs the Apple II, we already have IBM mainframes that have solved every useful problem in computing much better."
To add to that the W3C maintained the Amaya "browser", or web editor how they liked to call it, for like a decade and a half, as their vision for the web.
I think it was not just an appealing idea but Amaya itself was a solid implementation for a "testbed" (again, their words).
I can see why it died but I still think it is a bit of a shame it did.
Saving files locally was the same as saving files on the web in the original TBL context.
Imagine having a nice UNIX workstation on your desk at a university. This would resolve to machine.department.university.ac.uk rather than be hidden behind a router. If you wanted then you could run an x window on it or transfer files to and from it.
With standard issue Netscape of the era you could save an HTML file locally and it be fully accessible anywhere on the web.
The university would have the skills to setup the network for this, which was a difficult skill at the time.
In reality you would not save everything locally. The main department server would have a network share for you that would be mounted with NFS. So your files would be 'saved locally' over the NFS share to resolve to department.university.ac.uk/user.
You could also login to any workstation in the department for it to mount your NFS shares, with PCs of the era usually capable of running x windows and NFS in the university setting.
Servers physically existed in the server room rather than in the cloud.
I much preferred this model as, on SGI workstations, you had it all working out of the box. All you needed was some help with the networking.
Also important is that the web was originally all about structuring information rather than hacking it to make it pretty. It was up to the client to sort out the presentation, not the server.
In time we lost the ability to structure information in part because the 'section' element did not make it into HTML. Everyone wanted the WYSIWYG model that worked with word processors, where it was all about how it looked rather than how it worked.
We proceeded to make HTML that started as a soup of nested tables before the responsive design people came along and made that a soup of nested div elements.
Eventually we got article, section and other elements to structure information, but, by then it was too late.
It is easy to design something that is incredibly complicated and only understood by a few. It is far harder to design something that is simple and can be understood by the many.
We definitely lost the way with this. Nowadays people only care about platforms such as social media, nobody is writing HTML the TBL way, with everything kept simple. HTML has become the specialist skill where you need lots of pigeon holes skills. Nobody on these teams of specialists have read the HTML spec and no human readable HTML gets written, even though this is fully doable.
It seems that you are one of the few that understands the original context of HTML.
Ummmm all the browsers I know of are also editors... Are there any that aren't?
Edit - does no one use dev tools anymore? No HTML? No vanilla JS and CSS? Everyone just using TS, React and gluing things together? Like, you literally have an entire IDE in your browser (assuming you use anything derived from Chrome, Firefox or Safari) that can code a web page live...
You're describing built-in developer tools for editing local files during development. The comment you're replying to is describing the vision of a browser which can edit remote files as part of the normal user workflow, not as a developer-only activity.
NeXT machines were hardly mass market user machines... They were almost exclusively developer machines.
Also Chrome does have stuff like SSH extensions.
That being said, some of the computing paradigms of the 80's and early 90's were very cool and I wish they caught on... Lisp machines, Smalltalk, early web ideas were interesting...
Netscape had a JavaScript debugger, IE had a debugger as well. What firebug did was pull the inspector, debugger, console, and everything together in a really nice dev experience. The goal posts were moved far back and the major browsers hurriedly released their “dev tools” to counter FireBug. Chrome being the first after, followed shortly by Safari (who already had an inspector). It would take MS another 6 years to do the same for IE8.
I am trying something similar: I made game as a standalone HTML file with a feature that allows users to edit text and save as a new local version. Works on my phone (Android with Brave) but not on iOS with Safari.
TiddlyWiki is another (20+ year old and still being updated!) took in this space. It looks like hyperclay is a bit more oriented towards multitenancy and database-backed persistence than TiddlyWiki (very much trying to be a single-writing-user tool) after a quick read?
I am trying to figure this out. The writer despairingly says a backend is needed to store changes in state. The writer calls this backend DB and API. The writer then substitutes DB and API with "server" like it is a solution
So now we have a webapp. The webapp connects to a backend. The webapp stores changes in the backend. The webapp loads changes in the backend.
The original problem still persists?! State can be stored in browser with localstorage. Or in device with file access. That is about it. Across devices, you need online storage and access key.
I feel like this was a writeup on the problem with vanilla HTML app development.
Also, can we all agree that calling a webpage an app is an afront to all webpages? We should have two categories: webpages and webapps. A web page can contain a webapp. A web app is anything where the content changes and where it connects to a backend to store or load data. So interactive html stuff is not a webapp, but JS literally changing the data makes it a webapp, even a simple HTML page with a JS clock makes that portion of the page a webapp.
Interesting idea. Well put it on the list of things I should try some day.
After a quick look at the site, I like the idea. But I wonder where it's limitations start to get in the way.
How about security, if I can modify the page, who else can? And who controls that?
How much code and logic does it handle before getting difficult to maintain? And how much data?
If I make an useful app with it, say to track beers, can I share the app with other people without so they can track their own beers, without sharing my personal data?
1. Security: It operates under the same security model as most website builders (think SquareSpace), we completely trust the end user to modify their own site in their own best interest. If the end user violates this trust, they will lose access to their paid account and could be liable to damages from other users. Their actions, their consequences.
2. Who can modify: You can modify any app you create. You can also "enable signups", which allows other users to easily fork your app, but they all trace back to your source app. We're making a plan right now where you can ship updates to forked apps.
3. Difficult to maintain: Pieter Levels (of NomadList) famously codes his $60k/month apps in single index.php files, so I suppose it matter how you organize your code and what level of navigating-through-the-cruft you're comfortable with.
4. Other people can fork your app and track their own beers. We also want to integrate collaboration features, so 2 people can have control over the same page simultaneously, but for now it's best for single-user apps.
This is really neat! It echoes many of the ideas we've been exploring with the Webstrates project (https://webstrates.net). We've been using the DOM as persistence layer for building malleable collaborative software for smaller groups, whereas hyperclay focuses on using the same mechanisms for traditional webpages.
Recently, I have been experimenting with a local-first approach to Webstrates (https://github.com/Webstrates/MyWebstrates). Might be interesting to explore if a Webworker-based approach like in MyWebstrates could be used for offline editing in hyperclay.
Hi Clemens, I'm a big admirer of yours and what you're doing with Webstrates. I first heard of you about a year ago, when I was first exploring the ideas that became Hyperclay.
I love the idea of a local-first Hyperclay. Offline editing is one of the pillars of personal software and I'd like to head in that direction.
Would you be open to hopping on a video call at some point? I'd love to compare notes.
HTAs were equal parts great (for their time) and terrible (plus they stuck around until IE died): a bog-standard webpage, but IE-only and with local-user process execution powers. Also, the local persistence was...problematic.
This is a version that lets you easily update HTML apps locally. The hosted version is for when you want to share your apps or let other people fork them online.
But the ultimate goal is to have an ecosystem of where you can host/deploy/use HTML apps, including other competing services.
To take this concept one step further towards perfection, you would want to lose the backend completely and persist directly to a git repo using https://isomorphic-git.org/
And if keeping in local storage a list of all pages, you can create an index html automatically in a predefined format which makes it more of a database rather than loose documents.
I wrote a simple file encryption app some years ago that is a single self-contained HTML file. When you use it to encrypt files, it outputs another self-contained HTML file with a copy of the encrypted data inside, along with the code to decrypt it (if the correct password is specified): https://hypervault.github.io/
I've been thinking for a while that the web really suffers from not having a built-in concept of (ideally fairly anonymous) identity. I shouldn't need to maintain a whole authentication system and a database full of PII just to let you see the same data across your laptop and your phone...
HTTP auth is not an authentication system, it only describes how credentials should be passed from the client to the server and how the server should respond to them.
No, specifically not. I don't want to store your username and passwords in a database (and then deal with account recovery, password rotation, etc) - I want identity.
The browser should be able to vend me an (opaque, anonymous) token that identifies you as an individual. If your mobile and desktop browser vend the same token, then the website sees you as having the same identity on both platforms.
The privacy implications of this are a deep and toxic swamp into which every previous attempt has sunk. Right now, control over an email account is the best we've got.
> Right now, control over an email account is the best we've got.
And it's a poor enough solution that we have to build extra layers around it (for example, Apple's auth "login with Apple ID", which lets you hide your real email address behind an anonymous relay)
You could, but it's at the behest of the client, so browsers would have to implement that for it to be useful. If browsers are going to implement something, might as well come up with a decent standard.
Initiatives like this that makes creating web pages more direct are great!
I've done something similar using IPFS for persistence [1]. The format is different - it's a tutorial starting out with the dev tools that guides you to build an editor + site.
I wish that IPFS was more usable and mature as a general web technology! I've considered trying this with Git as the backend, but I haven't done much research into what the tradeoffs or complications would be?
> Whenever the page changes—or the user explicitly saves the page—we grab all the HTML, make a few modifications, and then POST it to the backend’s “save” endpoint.
Wait, so instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit (e.g. a small profile description change) ? What about if the webmaster then wants to change the HTML title of the profile description block ? The user's version just diverged from the webmaster's ?
> instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit
Yes. In exchange, we get a portable, malleable, self-contained application. That's the tradeoff.
> What about if the webmaster then wants to change the HTML title
1. The webmaster owns my-app.hyperlay.com (or somecustomdomain.com).
2. The user forks their version and gets user-version.hyperclay.com (or user-version.somecustomdomain.com)
You need to fork before editing. In the future, we'll have support for shipping updates to forked applications that can be accepted or denied by the end users.
The author (me) was strongly inspired by TiddlyWiki -- I love that software and wish it was allowed to proliferate more. If only browser vendors allowed their users to persist HTML files back to their own machines, we'd have a whole new ecosystem of personal applications!
I wish I could change the name from Hyperclay to TiddlyApp :)
Thank you for your kind words, much appreciated, speaking as the creator/maintainer of TiddlyWiki. I really like what you've done, and the way you've described it on the site. I hope you will enjoy success with it, and have as much fun with it as I have with TiddlyWiki.
> If only browser vendors allowed their users to persist HTML files back to their own machines, we'd have a whole new ecosystem of personal applications!
How does versioning work? After you fork an HTML app, is there a way to update it and get newer features without manual intervention?
I'm thinking about the Kanban board example I saw in the demo video. It looks like column re-ordering wasn't supported yet. What if I fork the app, put time into creating my Kanban, then I want to update to a new version that supports column re-ordering?
I really like this. If you ever plan an AMI with this, deploying hyperclay on maybe a t3 instance, installing Node.js via the package manager (https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-...), and then setting up the Hyperclay server using npm to handle requests, I think a lot of startups could be users. Would it be fair to say that Hyperclay could offer a lean way to rapidly prototype and iterate on MVPs, like landing pages, dashboards, or user-feedback-driven tools, where frontend changes (e.g., A/B testing UI elements) automatically update the underlying HTML source for instant deployment??
If it was marketed to startups to reduce development overhead by eliminating separate build pipelines or servers, allowing small teams to focus on core features rather than infrastructure, definite winner. Not sure how much your into AWS but this made me think of an AWS partner we use HostJane could use Hyperclay to help bundle cost-optimized spot instances for testing (mainly tech startup clients - https://www.hostjane.com), then push out a seamless CI/CD via CodePipeline, global distribution through CloudFront, Hyperclay could enable clients to scale from proof-of-concept to production affordably while maintaining full control over their app's evolution without vendor lock-in. Potentially doing away with complex databases or backend frameworks... amazing, well done!
I tried one of the demos and it didn't work; my changes were not persisted when I refreshed the page. I don't know how it's supposed to work, exactly, but a single self-contained HTML isn't it.
I too have an odd obsession with keeping everything in 1 file.
I recently (as an experiment) exclusively vibe-coded an Asteroids clone (with a couple of nifty additions), all in a single HTML file, including a unit test suite, which also works on either desktop or mobile: https://github.com/pmarreck/vibesteroids/blob/yolo/docs/inde...
Playable version (deployed via github docs) is here: https://pmarreck.github.io/vibesteroids/ Hit Esc to pause and see instructions (pause should be automatic on mobile; can re-pause by tapping top center area).
Type shift-B (or shake mobile device... you also would have had to approve its ability to sense that on iOS) to activate the "secret" ability (1 per life)
No enemy UFO's to shoot (yet) but the pace does quicken on each level which feels fun.
It doesn't update itself, however... (and I just noticed it has a test fail, and a test rendering bug... LOL, well at least the tests are valid!)
This is a really cool idea. The use of custom attributes without `data-` before it makes me a little nervous. Is that a concern here? I saw `project` being used on elements and if that's officially used for something eventually can it muddy things up?
HTML5 is surprisingly lax about using arbitrary attributes and tags: any attribute or tag without a dash in it could potentially conflict with a future version of the spec, but it doesn't go out of its way to forbid them either. data-* attributes are special in that they appear in the .dataset property in the DOM, but anything with a dash should be future-proof against the HTML spec.
Very good. I was wondering why nobody did something like that before. At least this was my conclusion from my google searches few months ago. From a design perspective, I don't like storing state in the DOM itself, I would have find much more flexible to have the state in a json as a single source of truth and use reactive patterns such as state change => ui change and not hiting the DOM directly. That sounds like big framework things, but it saved me from acute headaches in a personal similar framework I did for self-contained apps. It was not HTML but I thought I would apply the same logic if I had to do it for html apps too.
Also our Webstrates (https://webstrates.net) system stores state in the DOM itself. But it's more a system for research prototyping than publishing web pages.
This is just awesome! But seems like a closed source project, and the pricing page returns HTTP 404.
Are there any open source alternatives like this? First time I hear about this idea. However, I can imagine it wouldn't take much effort to implement the basics. Chromium even has a design mode you can activate by typing `document.designMode='on'` in the console. Then you would just need to write a little javascript that handles auth, a save button, and a backend to persist the altered html.
fwiw, for this kind of tech - personal level projects - there is not a snowball's first summer outing in hell's chance I'm going to pay for someone else to host my thing remotely. I would like to just self host, and if it was good I would buy a license for it so I can self host - but I think you have a customer in mind that doesn't exist.
Your ideal customer a) is extremely technically proficient, such that they are even capable of finding this in the first place, and their brain doesn't glaze over at "jQuery is Your Starting Point" - the opening line of your docs. b) They for some reason would rather pay for someone else to do the world's easiest hosting job and deal with whatever baggage and limitations come with this.
Or am I misunderstanding? Like it's a nodejs server on some aws box. Charging people for this is fine, but not allowing them to do it themselves seems... ridiculous?
You gotta eat, I know, but I'm wondering who it is that is ok paying for someone else to do the easiest part what they do for a living.
I think you're underestimating the market here. It's not just extremely technically proficient people, it's the glitch people, the "custom myspace theme" people, possibly even the jsfiddle people.
The `/save` endpoint looks almost trivial. Knocking up a mimic wouldn't take much. The client libs will be interesting, but from the looks of things they're not quite there yet.
Mavo seems pretty similar, saves to github, allows flipping the UI to admin/editor mode https://mavo.io/
I really liked this when it was launched and thought it had a great deal of potential when it launched. I think the main difference is that it's more focused on content-editing, not updating the code of the page itself.
Slightly tangential: a lot of my vibe coding experiments are standalone SPAs because I can't be bothered to set up a secure server (and I am too cheap to pay for it). I love that I can open my "mobile-first" apps directly from my phone's Downloads folder.
I have a feeling that a lot of these little tools people make with low-code vibe AI apps do not require more than a single HTML page with JS imports.
(I also suspect that there is a ton of duplication in what people create, but, of course, I have no data to back it up.)
This is great and all (I've been making my own standalone web app htmls), but one issue I've found when sharing with others is iOS (iPhone/iPads) don't support them.
Apple ugh.
Any suggestions how to overcome this? I believe it's a security setting, not allowing localstorage to be set.
I am not sure how this proposal deals with the problem of templating. If you have a bunch of documents (say, blog articles) that should have a consistent layout, you are going to want to create a template for them. But then the document you see isn't the "true" document, and in order to save the content you're going to have to annotate it to "reverse" the templating.
If it does this, then it is very exciting indeed, but I could not see it.
I really like this idea, I envision something where this would be made possible on browsers now. This could only happen after further consideration about the security implications of localhost html files using secure context apis like indexeddb and localstorage The powers that be would rather turn this concept into a mArKetPlaCe -- Just let us create! Why must we always kneel before the altar of capitalism?
I experimented a bit with the concept to build my resume, I had naively been using gatsby a while back. "Just use a plain html file!" - It was a real "duh!" moment. You just edit the embedded markdown then viola. Want a pdf? Press cmd+P
... I would like to up the anty and have web apps work in a portable vanilla HTML file WITHOUT needing a webserver to run it. E.g., double click and run. CORS be damned!
Webservers are a pain in the ass and a legitimate barrier to entry. Wouldn't it be great it you could literally send around a single file, especially to non-technical users who cant run a web server, to run your apps?
This is what people did before web apps. Package a binary and ship it to customers.
Problems with the approach:
* Customers still ask you why stuff doesn't work, except now it's their hardware
* Observability is not as strong on self-hosted solutions
* There is no true universal binary, so no matter what you have to put constraints up (only runs on windows, mac, etc.)
* Updates are way harder
Browsers are built to browse the web, trying to remove the web out of browser apps seems illogical
It's even easier with Go + templ. You can compile a whole site into a single executable file, in the range of 20-30MB. Use sqlite with it and you've built yourself a portable and dynamic site capable of running almost anywhere in an instant. Use nginx load-balancing with a central sqlite if you need to scale
I've built some single-file HTML page tools at work that use newer Web APIs (WebSerial, WebUSB) and essentially utilize the browser as a cross-platform application virtual machine, which is a great way to think about browsers. With WASM compilation, Canvas, and WebSockets, combined with this self-modifying concept where an HTML file is a contained, stateful application that can persist, we've got very interesting possibilities for the future of user-facing applications, both local and fetched remotely. This is probably exactly what some of the visionaries at Google were thinking of when they concepted the Chromebook and Chrome OS.
> The coolest part? It's just an HTML file. Nothing special. Change it, it serializes its DOM, and sends it to a /save endpoint. Nothing magic about it.
*The tech: Hyperclay is a NodeJS server and frontend JS library*
I for one, like the fun you had on the page. Ignore the haters. Only critique would be you should just explain how it works near the top. I think most devs myself included want to first understand what it is before the why it’s awesome.
ps. Way back there was a project called tiddlywiki that was a self modifying html file and was pretty popular. I think initially there was no way to save new version but to basically save the file to disk to either fork a file or replace itself.
Honestly I was nodding along with the landing page. But including a dependency to an old timey JS library which is now largely unnecessary given new native web APIs? That seems contrary to the spirit of this project.
Every time I see projects like this what I hear is: “I hate JavaScript, just use html and web standards (oh and a bunch of JavaScript but I hate JavaScript so let’s not talk about it much).”
The playground has lots of unique features, CLI agent integration for AI to let you collaborate with Claude Code or Codex CLI, etc. You can deploy straight to https://RTEdge.net
The playground has HTML I ↔ O iframe with mostly reload-free 2-way IO sync, built-in service/edge workers with URL imports of ESM, and a whole lot more. You can see some examples under Code > New…
Here is a recent one for accessible multi-OS keyboard shortcuts: https://kbd.rt.ht/?io
For people who are confused: Hyperclay is a NodeJS server and frontend JS library that allows HTML pages to update their DOM and then replace their own .html source with the updated version.
Imagine clicking a checkbox, which adds the `checked` attribute to its element, then using Hyperclay to globally persist this version of `document.body.outerHTML`, so that it's there next time someone visits the page. There's automatic versioning and read/write permissioning.
It's a pretty cool project! I'll definitely try for my own personal tools.
Do note that, from my understanding, it's most useful when there's one developer who is also the only content editor. Otherwise you'll have editors overwriting each other's changes, and if there are multiple copies there's no easy for the developer to push a change to all copies.
I'm still confused - if it requires a NodeJS server, then it wouldn't be a fully self-contained HTML file would it?
It technically doesn't say "self-contained", but it does say "portable" and "self-updating", which I must agree is misleading.
I added this word-for-word to the home page. Thank you!
Note: we are working on a way for a developer to push "DOM-based schema migrations" to all forked apps.
I'm flattered you liked my description so much! It's a really special project, thanks for sharing it.
I love this, I think this brings "block editing" capabilities to the masses, which is a big selling point for WordPress. In recent months, I've been looking at micro-sites and I concluded that Carrd is king for this type of landing pages/microsites. So this looks very promising for this respect. Either of you care to share or dispel security concerns or describe attack surface? For the past 6 months I've been looking at HUGO sites and the simplest deployment approach I found was alpine/sqlite/hugo containers at 5-10mb in size. Is there a way to delegate control/editing of sections/pages? I think the world needs a simple platform to build sites and delegates sections to respective departments/units. The only platform which seems solid for this is drupal, but it's kind of overkill for SMB orgs.
Thanks. Author mentioned TiddlyWiki as inspiration. But the whole point of TiddlyWiki was that it doesn't need a server right?
So I'm trying to understand the difference, the payoff. I understand that local web APIs are ass and you very quickly run into the need for a server.
But I'm wondering about the utility of combining the two approaches. It seems like a contradiction in terms. Here's a server to help you with your dev setup oriented around not needing a server.
I guess the main win would be cross device access? You have it online and you can edit it easily.
I'm editing my stuff on my phone in a text editor. And syncing it to my laptop with a sync app.
Turns out, the original TiddlyWiki used a java jar to handle the file persistence. (I remember it being so magically automatic, but recently investigated how it was done)
Thanks. Author mentioned TiddlyWiki as inspiration. But the whole point of TiddlyWiki was that it doesn't need a server right?
I did a deep dive on TiddlyWiki recently. No, it doesn't need a server; an entire site can be self-contained in one HTML file.
If you want to run it as a multiuser, web accessible wiki, it runs on top of NodeJS.
How would TiddlyWiki write to filesystem (save) without a server?
I thought opening index.html in the browser was basically just a demo.
Tiddlywiki has two modes of running. In one, you simply save the file as HTML and all your content is saved inside the file.
The other mode is with a nodejs server (it's what I'm using). This allows me to access the wiki from all devices.
I see, so you make edits, the Javascript edits the html, therefore File -> Save Page will download an html file with your changes in it that you can open again.
I forget that File -> Save is even a thing for websites.
TiddlyWiki can replicate itself. All users can freely edit any TiddlyWiki and save their changes to their filesystem. There's a few options for exports.
It is a common gotcha that new users will lose some of their work while they learn persistence.
iirc browsers used to allow direct filesystem access.
They never did, if anything it's the opposite in that I think there are now APIs that can make this possible.
With TiddlyWiki you had to essentially File -> Save As and save the HTML back over itself. There were other ways too but they were all workarounds to the issue that browsers don't allow direct access.
They did back around 2008. I used Wiki on a stick - see https://stickwiki.sourceforge.net/which was kind of neat) but after a few years, Chrome etc stopped letting it save itself.
Thanks for the description, I kept reading the webpage and didn't understand what the project was or how it worked. Yours is really succinct and clear.
To be completely honest, I don't see how this is more useful than adding a sync layer to localStorage. I did make a service that does that at htmlsync.io and am genuinely curious how this solution is better.
Just like with https://tiddlywiki.com/
Your notes are the HTML file! You can keep it in your documents folder, sync it via any service, track it in version control, etc. It’s for folks who know what the filesystem is, don’t know how to host a server (or don’t want to), but want a website-like experience. Works offline, too!
I finally also recalled this project (tiddlywiki), but CMIIW, the statefulness of the hyperclay is only for developers, the end user will get the same conventional html. Without some kind of common solution/protocol/standard on the browser side that would allow persistence it's not so exciting. Theoretically there might be some kind of simple protocol that would save html file versions on the server based on the cookie, but there are so many ways this can go wrong
So like, Obsidian, but for HTML?
The file itself provides both the dynamic functionality and data storage, but you need an engine (like obsidian) to make the data persistence and dynamic parts work together. I.e. if there is a button that adds a task to a todo app, your engine modifies the HTML file with the new content.
The idea would work a lot better with something like Cloudflare Workers. You don’t really need it to run 24/7 and it would fall into the free tier.
This all sounds like something from 2001. I was doing pretty much exactly this around 2001, using contenteditable with an IIS/JScript back-end.
I think contenteditable is more akin to a rich-text document, while Hyperclay goes a bit beyond by allowing JS to edit the DOM too. I think Smalltalk images and virtual machines are a closer comparison, but applied to the web. You download the image, with some running code, use it, and persist the whole application state.
Yeah, sounds like Tiddly Wiki or similar except with the need for a backend component.
Edit: actually it looks more like a library/framework to make such apps. And now I'm not sure if it needs a backend component or nodejs or not.
If I need a server to run this then surely I can use sqlite and save different versions of the page without overwriting the html page every time.
How does this differ from htmx?
htmx is a javascript library that reads configuration from html attributes and sends http requests based on that configuration
hyperclay is a web server that stores and serves versions of html files
htmx requires a server. This enables a single html file to modify itself.
But it needs a server too?
No, this need a server too. Everything that saves changes to non local (shareable) locations needs some kind of a server. The best solutions are of course when OP hosts the server and you pay for it /s
So it's a wiki?
I don't get it.
Wiki has specific content you can add. New article, body of an article, etc. This lets you change all the html. With this, you could edit your wiki into a calculator.
I like it!
I would like web standards have better support for pages stored in a local file (opened using file:// protocol). Sometimes I write simple HTML/Vue based mini-apps for myself and every time something doesn't work and I need workarounds, for example:
- local HTML file cannot import local JS modules, so I have to use legacy writing style
- local HTML file cannot open other local files (for example, audio files)
I understand that there is a risk if we allow local HTML files to access anything, but there should be some way - for example, a file or directory might have some suffix that allows access to it.
I do not want to use a web-server because it feels like overengineering and I don't want to open a terminal, navigate to a directory and start a server every time, it takes too much time. I just want to type the URL and have my app running.
> I understand that there is a risk if we allow local HTML files to access anything, but there should be some way - for example, a file or directory might have some suffix that allows access to it.
> I do not want to use a web-server because it feels like overengineering and I don't want to open a terminal, navigate to a directory and start a server every time, it takes too much time. I just want to type the URL and have my app running
I'd love for there to be an "offline only" mode for browsers where you can either access the local filesystem or remote pages, but not both. I don't think this would completely solve the use case you describe, since there would still presumably be circumstances where it would be helpful to reference something external, but it feels like it would be pretty useful to be able to use a browser as a limited server for static files, and it would be relative simple and intuitive compared to needing to have something in the files themselves indicate the intended semantics.
A significant hindrance for generator-type apps is that only pages loaded via HTTPS have access to the clipboard API, so ”copy to clipboard” does not work via file:///.
You can have a zero-build zero-dependency offline-only app which users could theoretically just save as a page, but copy buttons will not work, so you have to detect the API not being available and replace buttons with popover textareas. Clunky.
As for running a local server, VS Code devcontainers are the solution. Open your workspace, it runs the devcontainer, and you have a server up without extra hassle. Add a command to generate certs and you can have HTTPS locally.
This is so weird that a random website on a random server (having SSL doesn’t change that in the slightest) is considered less of a risk than a file I have on my own computer.
Can somebody help me understand what’s going on?
There’s some discussion in the specs here https://w3c.github.io/webappsec-secure-contexts/#is-origin-t...
> In particular, the user agent SHOULD treat file URLs as potentially trustworthy.
> User agents which prioritize security over such niceties MAY choose to more strictly assign trust in a way which excludes file.
A potentially trustworthy URL is a secure context: https://html.spec.whatwg.org/multipage/webappapis.html#secur...
So this is a matter of browsers not implementing it, probably because there’s just not a lot of demand for it.
The rule was probably intended to block public non-SSL pages, so your clipboard data doesn't ever get sent over the wire unencrypted.
Why does it block local pages? Well what benefit of is to Apple or Google if it were easier to make good localhost webapps?
Try deleting Safari site data(indexed DB etc) for your localhost site. You won't be able to. Hell, even deleting data for a specific public site is hilariously painful. Try adding a certificate authority to your iPhone. Try playing locally cached audio blobs via web APIs on an iPhone. There's probably 1000 more.
The random website cannot access arbitrary files on your computer's file system and send it somewhere else. An html file with javascript running locally, if trusted, on a typical personal computer could do that.
There should be some way to mark files as accessible, for example, place them into a folder with a specific name (like "html-accessible-files") on the same level as HTML file.
> As for running a local server, VS Code devcontainers are the solution. Open your workspace, it runs the devcontainer, and you have a server up without extra hassle
it's not easy to install VS Code, let alone use it. VS Codium (and VS Code) are Electron apps, and it is difficult to sandbox them, as Electron (and Chromium as well) use suid helper - a priviledged binary that launches as root, and I won't allow suid binaries in a sandbox. Also, it requires GPU access for fast rendering, and it is difficult to provide in a safe way or switch to software rendering (I couldn't figure it out). Electron apps are a pain to install.
One could use a virtual machine, but it would use more resources.
Obviously, that's not VS Code's issue, it is a problem with Linux which doesn't come with a good sandbox.
It is much easier to type python -m http.server to launch a server, but you need to open a terminal and navigate to a directory first, that takes lot of time I would rather spend on something different (like figuring out how to work around issues with suid binary in Electron apps). And this looks like a hacky workaround, launching a web server only to gain more privileges in a browser.
> but you need to open a terminal and navigate to a directory first, that takes lot of time
It does?
It does, given that I don't always remember the path to the app. Also, on my Linux system the terminal doesn't remember windows and tabs and I have to open them all manually after reboot (I could ask ChatGPT to write a script for that but it would be easier if I hadn't to).
Maybe you can associate html files with or use open with to pass them into a script that calls python -m http.server and creates and opens a url to the file via the python server in the browser.
Chromium based browsers treat localhost as a secure context, so HTTPS isn't required to access APIs like the clipboard, web serial, etc.
Not just localhost, but *.localhost too. It's not just Chromium, it's a standard that Firefox supports too (Safari as usual is kind of spotty): https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
Windows used to have HTA applications, html files with a different extension that opened in a browser without menus and had access to filesystem APIs over javascript (jscript). It was probably a security nightmare, but I could see a modern version of that built on electron. Access to a folder and a sqlite db would be enough.
There's also Orca for building sandboxed wasm apps but it removes the browser and the Dom and only gives you a canvas to work with.
I was annoyed too when they started to close off HTML as a local platform.
But! it is still very open (you complain about audio and javascript but they both work) also I've figured that it isn't really much of a problem to start a python/node webserver for the things I'm not allowed to do. Literally a fraction of a second. Just set up a "webserver_here" command in your terminal, or keep one running constantly. Also I'm starting to fear local HTML more and more, I'd actually be happier with a much stricter boundary.
This is quite similar to what I was trying to explore with [1] & [2] yesterday. Currently, the only option I found is to use localStorage and give the user the option to manually export and import.
Hyperclay has given me some ideas. What I want is something like [3] but that the user only needs to install once. One electron app that can load our mini-apps.
[1] - https://news.ycombinator.com/item?id=44930814
[2] - https://news.ycombinator.com/item?id=44933897
[3] - https://www.electronjs.org/fiddle
I had the same problem, regarding localStorage synchronization. For that I made htmlsync.io, but only really worth it for people who have many local apps like that and really need the localStorage sync.
This is pretty cool! What kind of users are you targeting? Technical folks or those dipping their toes into dev with vibe coding?
Thanks! Pretty much, yes. Also if you are a dev and just don't want to spin up a server for every simple app you vibe code, you could find this useful.
To be honest, I wanted this for myself and felt guilty not making something more serious out of it since I liked the idea.
“…I don't want to open a terminal, navigate to a directory and start a server every time, it takes too much time…”
I have a shell script that does these steps - including opening the browser with the target url. I use it on a regular basis.
The local html file can read local resources via src=file_path attributes on html tags (img, audio, video, script etc).
But the src-included files must be in the same directory as the root html file (or a descendant directory)
I used this in my macOS app Pocket Log to output a local html audio log (https://enzom.dev).
Sadly it doesn't work for JS modules, only for legacy JS scripts.
I have been using python http server to get this working. Go to a place where you have your index.html, start a python server, python3 -m http.server, and voila, everything is now importable and locally accessible.
It's been a while, but if I remember correctly you can't use some <canvas>/WEBGL features on images that are loaded from file:// URLs because of CORS (I think it was off-screen canvas). The only workaround I found was to embed the images inside the HTML using base64.
And to embed them you need a build step, and setting it up might take longer than writing the mini app itself.
I appreciate the storytelling and the nice graphics, but after reading 10 screen lengths of this story I still don't understand what technology they are using to achieve this.
Is it a lot of words to talk about localstorage? How exactly are the changes persisted to the HTML file? Is it using FileSystemAPI to overwrite the previous HTML file? How can they implement it seamless for the user without them having to choose the proper file in the "Save As.." dialog?
There's two approaches Hyperclay takes.
1. Hosted: You get a bunch of "HTML Apps" that persist themselves by calling their own /save endpoint. We grab the HTML and overwrite their-app-name.html, making a backup/version along the way. (Each user can edit their own app only, but they can also enable signups so that other people can fork their app. We also have plans to allow them to ship optional updates to forked apps.)
2. Local: You download the open-source Hyperclay Local [0] and you can have your own personal, local HTML apps that also call the /save endpoint and make backups. You're also open to extracting the core code from this to host your own personally malleable apps on your own server (just implement some kind of auth)
[0] https://hyperclay.com/hyperclay-local
So… it's a server that stores HTML files?
Sounds like modern version which replaces FTP access with nodejs server. But you have to host it on a server or pay monthly fee anyway so you do need a server. AKA ad for OPs business.
And probably uses the Mutation Observer to capture DOM changes
https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
I'm also a bit lost after scrolling through it. It seems if we take this one step further and add a bit of syntax to HTML to be executed on the server you'll have invented PHP / WordPress right?
AFAICT this is another cycle of; a decent system becoming overcomplicated because someone wanted to make it multi-tenant, and the re-discovery that 90% of the "improvements/advancements" are essentially bloat in the context & freedom you find/create.
I have to say, it feels rather strange to read
> It would be a great to ignore all the noise of modern web dev and just build the experience I want
sandwiched in between meme images that intersperse short bursts of text as if the reader needs constant distraction from the act of reading.
The experience I want is a short prose description up front, backstory that flows, and diagrams only where they actually illustrate a concept that needs it.
There's a DB on the server. It's just storing HTML with all its views instead of storing JSON, an extract of the information that is allowed to change...
From what I understood the html file itself is updated so it's updating forms, attributes and other tags to include the new changes
Then that file is posted to the backend for persistence
This is coming close to WWW's original vision because the very first web browser was also an editor. Tim Berners-Lee's application on the NeXT was basically a wrapper for the operating system's built-in rich text editing class named TextView. (It later became NSTextView on Apple's Mac OS X and still powers the TextEdit app on Mac.)
We lost editing for two reasons:
1) The HTTP PUT method didn't exist yet, so edited HTML files could only be saved locally.
2) Mosaic built a cross-platform web browser that defined what the WWW was for 99% of users, and they didn't include editing because that would have been too complex to build from scratch in their multi-platform code base.
Making a more read/annotate/write web is near and dear to my heart. There's a lot I find admirable - noble about pages like Hyperclay!
But also, it's a distinctly different answer for each page to build its own toolkit for the user (Hyperclay) vs TBL's read-write web. The user-agent ought, imo, afford standard tools that are going to work across web pages, that extend the user agency whatever site they are visiting.
Yes, I agree. My dream would be to one day work on a browser and integrate Hyperclay into it. I believe web apps have been around long enough as a core web technology that browsers should ship with a local web host, knowledge of what a user and user account is, and the ability to persist to disk whatever the user chooses.
In a similar vein, it looks like there is a working group for linked web storage at:
https://www.w3.org/groups/wg/lws/
That would likely have some overlap.
If you were to have an accepted w3c proposal and working implementation in local browser forks, you could potentially chat with the browser teams to add the experimental feature first through a flag users would manually have to turn on, and then later potentially it could get integrated.
> Making a more read/annotate/write web is near and dear to my heart
Isn't that basically Wikipedia? I can't imagine a much simpler system that could work at modern web scale.
I think the scale difference is the whole point. Wikipedia has billions of active users, while these Hyperclay-style persistent documents have only a few.
Saying "we don't need this because Wikipedia already solved it" is kind of like saying in 1976: "Nobody needs the Apple II, we already have IBM mainframes that have solved every useful problem in computing much better."
To add to that the W3C maintained the Amaya "browser", or web editor how they liked to call it, for like a decade and a half, as their vision for the web.
I think it was not just an appealing idea but Amaya itself was a solid implementation for a "testbed" (again, their words).
I can see why it died but I still think it is a bit of a shame it did.
I had never heard of Amaya before.
> It supports HTML 4.01, XHTML 1.0, XHTML Basic, XHTML 1.1, HTTP 1.1, MathML 2.0, many CSS 2 features, and SVG.
Perfect. Doesn't need anything else.
Amaya is great when you just need to do some quick edits.
Saving files locally was the same as saving files on the web in the original TBL context.
Imagine having a nice UNIX workstation on your desk at a university. This would resolve to machine.department.university.ac.uk rather than be hidden behind a router. If you wanted then you could run an x window on it or transfer files to and from it.
With standard issue Netscape of the era you could save an HTML file locally and it be fully accessible anywhere on the web.
The university would have the skills to setup the network for this, which was a difficult skill at the time.
In reality you would not save everything locally. The main department server would have a network share for you that would be mounted with NFS. So your files would be 'saved locally' over the NFS share to resolve to department.university.ac.uk/user.
You could also login to any workstation in the department for it to mount your NFS shares, with PCs of the era usually capable of running x windows and NFS in the university setting.
Servers physically existed in the server room rather than in the cloud.
I much preferred this model as, on SGI workstations, you had it all working out of the box. All you needed was some help with the networking.
Also important is that the web was originally all about structuring information rather than hacking it to make it pretty. It was up to the client to sort out the presentation, not the server.
In time we lost the ability to structure information in part because the 'section' element did not make it into HTML. Everyone wanted the WYSIWYG model that worked with word processors, where it was all about how it looked rather than how it worked.
We proceeded to make HTML that started as a soup of nested tables before the responsive design people came along and made that a soup of nested div elements.
Eventually we got article, section and other elements to structure information, but, by then it was too late.
It is easy to design something that is incredibly complicated and only understood by a few. It is far harder to design something that is simple and can be understood by the many.
We definitely lost the way with this. Nowadays people only care about platforms such as social media, nobody is writing HTML the TBL way, with everything kept simple. HTML has become the specialist skill where you need lots of pigeon holes skills. Nobody on these teams of specialists have read the HTML spec and no human readable HTML gets written, even though this is fully doable.
It seems that you are one of the few that understands the original context of HTML.
> web browser was also an editor
Ummmm all the browsers I know of are also editors... Are there any that aren't?
Edit - does no one use dev tools anymore? No HTML? No vanilla JS and CSS? Everyone just using TS, React and gluing things together? Like, you literally have an entire IDE in your browser (assuming you use anything derived from Chrome, Firefox or Safari) that can code a web page live...
You're describing built-in developer tools for editing local files during development. The comment you're replying to is describing the vision of a browser which can edit remote files as part of the normal user workflow, not as a developer-only activity.
NeXT machines were hardly mass market user machines... They were almost exclusively developer machines.
Also Chrome does have stuff like SSH extensions.
That being said, some of the computing paradigms of the 80's and early 90's were very cool and I wish they caught on... Lisp machines, Smalltalk, early web ideas were interesting...
DevTools was not part of the original browsers. Firebug brought the concept to existence in the first place.
As a sidenote, does manipulating forms count as editing?
Netscape had a JavaScript debugger, IE had a debugger as well. What firebug did was pull the inspector, debugger, console, and everything together in a really nice dev experience. The goal posts were moved far back and the major browsers hurriedly released their “dev tools” to counter FireBug. Chrome being the first after, followed shortly by Safari (who already had an inspector). It would take MS another 6 years to do the same for IE8.
Netscape had editing tools. Firefox has editing tools. Chrome has editing tools. I think Safari does too?
Like, Netscape Composer came OUT of Navigator...
>Firebug brought the concept to existence in the first place.
There were other browser "dev tools" before firebug.
https://www.otsukare.info/2020/08/06/browser-devtools-timeli...
Crazy - I had forgotten about the earlier ones! The IE one I used at some point, and fiddler too
They are talking about a WYSIWYG editor like Netscape Composer
Been doing something similar with save files for my game. Line 1 is "<!DOCTYPE html><html><head><script>const rawData =" and line 2 is all the state.
Then the save button downloads document.documentElement.outerHTML with line 2 replaced by the current state. No server required.
https://github.com/mcteamster/white/blob/main/src/lib/data.t...
I am trying something similar: I made game as a standalone HTML file with a feature that allows users to edit text and save as a new local version. Works on my phone (Android with Brave) but not on iOS with Safari.
TiddlyWiki is another (20+ year old and still being updated!) took in this space. It looks like hyperclay is a bit more oriented towards multitenancy and database-backed persistence than TiddlyWiki (very much trying to be a single-writing-user tool) after a quick read?
https://en.m.wikipedia.org/wiki/TiddlyWiki
I am trying to figure this out. The writer despairingly says a backend is needed to store changes in state. The writer calls this backend DB and API. The writer then substitutes DB and API with "server" like it is a solution
So now we have a webapp. The webapp connects to a backend. The webapp stores changes in the backend. The webapp loads changes in the backend.
The original problem still persists?! State can be stored in browser with localstorage. Or in device with file access. That is about it. Across devices, you need online storage and access key.
I feel like this was a writeup on the problem with vanilla HTML app development.
Also, can we all agree that calling a webpage an app is an afront to all webpages? We should have two categories: webpages and webapps. A web page can contain a webapp. A web app is anything where the content changes and where it connects to a backend to store or load data. So interactive html stuff is not a webapp, but JS literally changing the data makes it a webapp, even a simple HTML page with a JS clock makes that portion of the page a webapp.
"Malleable" apps. Meaning the HTML file serving the webapp itself gets modified. Ok.
What happens if the user has an extension in his browser that modifies a page or adds JS to it? Will it get added to upstream?
Interesting idea. Well put it on the list of things I should try some day.
After a quick look at the site, I like the idea. But I wonder where it's limitations start to get in the way.
How about security, if I can modify the page, who else can? And who controls that?
How much code and logic does it handle before getting difficult to maintain? And how much data?
If I make an useful app with it, say to track beers, can I share the app with other people without so they can track their own beers, without sharing my personal data?
1. Security: It operates under the same security model as most website builders (think SquareSpace), we completely trust the end user to modify their own site in their own best interest. If the end user violates this trust, they will lose access to their paid account and could be liable to damages from other users. Their actions, their consequences.
2. Who can modify: You can modify any app you create. You can also "enable signups", which allows other users to easily fork your app, but they all trace back to your source app. We're making a plan right now where you can ship updates to forked apps.
3. Difficult to maintain: Pieter Levels (of NomadList) famously codes his $60k/month apps in single index.php files, so I suppose it matter how you organize your code and what level of navigating-through-the-cruft you're comfortable with.
4. Other people can fork your app and track their own beers. We also want to integrate collaboration features, so 2 people can have control over the same page simultaneously, but for now it's best for single-user apps.
This is really neat! It echoes many of the ideas we've been exploring with the Webstrates project (https://webstrates.net). We've been using the DOM as persistence layer for building malleable collaborative software for smaller groups, whereas hyperclay focuses on using the same mechanisms for traditional webpages. Recently, I have been experimenting with a local-first approach to Webstrates (https://github.com/Webstrates/MyWebstrates). Might be interesting to explore if a Webworker-based approach like in MyWebstrates could be used for offline editing in hyperclay.
Hi Clemens, I'm a big admirer of yours and what you're doing with Webstrates. I first heard of you about a year ago, when I was first exploring the ideas that became Hyperclay.
I love the idea of a local-first Hyperclay. Offline editing is one of the pillars of personal software and I'd like to head in that direction.
Would you be open to hopping on a video call at some point? I'd love to compare notes.
I'd love to. Drop me a mail and let's find a suitable time.
Someone rediscoved Windows 98 HTA archives.
https://en.wikipedia.org/wiki/HTML_Application
The original Electron! Pity the versions of IE it was available for were still hell to debug in.
Back in those days you had to install the Office Scripting Debugger, I think that was the name, when browser debuggers were still extensions.
HTAs were equal parts great (for their time) and terrible (plus they stuck around until IE died): a bog-standard webpage, but IE-only and with local-user process execution powers. Also, the local persistence was...problematic.
Only similar in the vaguest sense.
Before that it likely was Outlook Web Access.
https://en.wikipedia.org/wiki/Outlook_on_the_web
Came here to comment the same.
Looks like it's on Github at https://github.com/panphora/hyperclay-local
This is a version that lets you easily update HTML apps locally. The hosted version is for when you want to share your apps or let other people fork them online.
But the ultimate goal is to have an ecosystem of where you can host/deploy/use HTML apps, including other competing services.
This seems cool but the web site is not doing it any favors. I thought it's a joke but apparently it's a serious project?
To take this concept one step further towards perfection, you would want to lose the backend completely and persist directly to a git repo using https://isomorphic-git.org/
It stinks github or gitlab or any free git hosting providers didn't work with isomorphic git.
I like the idea! You would still need something to serve the HTML file, but that isn't so bad.
But in my experience the potential audience shrinks significantly once anything git related is expected from a user.
And if keeping in local storage a list of all pages, you can create an index html automatically in a predefined format which makes it more of a database rather than loose documents.
I wrote a simple file encryption app some years ago that is a single self-contained HTML file. When you use it to encrypt files, it outputs another self-contained HTML file with a copy of the encrypted data inside, along with the code to decrypt it (if the correct password is specified): https://hypervault.github.io/
Very nice concept!
I've been thinking for a while that the web really suffers from not having a built-in concept of (ideally fairly anonymous) identity. I shouldn't need to maintain a whole authentication system and a database full of PII just to let you see the same data across your laptop and your phone...
You mean HTTP auth?
HTTP auth is not an authentication system, it only describes how credentials should be passed from the client to the server and how the server should respond to them.
No, specifically not. I don't want to store your username and passwords in a database (and then deal with account recovery, password rotation, etc) - I want identity.
The browser should be able to vend me an (opaque, anonymous) token that identifies you as an individual. If your mobile and desktop browser vend the same token, then the website sees you as having the same identity on both platforms.
The privacy implications of this are a deep and toxic swamp into which every previous attempt has sunk. Right now, control over an email account is the best we've got.
> Right now, control over an email account is the best we've got.
And it's a poor enough solution that we have to build extra layers around it (for example, Apple's auth "login with Apple ID", which lets you hide your real email address behind an anonymous relay)
Could you put a token in a http auth username? Leave the password blank?
You could, but it's at the behest of the client, so browsers would have to implement that for it to be useful. If browsers are going to implement something, might as well come up with a decent standard.
Initiatives like this that makes creating web pages more direct are great!
I've done something similar using IPFS for persistence [1]. The format is different - it's a tutorial starting out with the dev tools that guides you to build an editor + site.
I wish that IPFS was more usable and mature as a general web technology! I've considered trying this with Git as the backend, but I haven't done much research into what the tradeoffs or complications would be?
[1] - https://www.thebacklog.net/projects/agregore-web-apps/
Am I the only one that does not understand what the author wants to explain ?
Do we need a story with illustration to understand how a new framework works ? What's the plain markdown 2 to 3 paragraph that explains the concept ?
Edit : here it is. https://docs.hyperclay.com/docs/docs-tldr-paste-in-llm/#how-...
> Whenever the page changes—or the user explicitly saves the page—we grab all the HTML, make a few modifications, and then POST it to the backend’s “save” endpoint.
Wait, so instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit (e.g. a small profile description change) ? What about if the webmaster then wants to change the HTML title of the profile description block ? The user's version just diverged from the webmaster's ?
> instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit
Yes. In exchange, we get a portable, malleable, self-contained application. That's the tradeoff.
> What about if the webmaster then wants to change the HTML title
1. The webmaster owns my-app.hyperlay.com (or somecustomdomain.com). 2. The user forks their version and gets user-version.hyperclay.com (or user-version.somecustomdomain.com)
You need to fork before editing. In the future, we'll have support for shipping updates to forked applications that can be accepted or denied by the end users.
Or you will rename one page, instantly breaking URL pointing on that page on all already saved pages.
I really want to see more HyperCard-style data persistence, where both the code and the data are one one document, so this is cool to see.
I was actually just playing with a similar concept, except as an Obsidian plugin: https://bsky.app/profile/ezhik.jp/post/3lwoazfypx22j
At first I thought it is tiddlywiki but it is not.
The author (me) was strongly inspired by TiddlyWiki -- I love that software and wish it was allowed to proliferate more. If only browser vendors allowed their users to persist HTML files back to their own machines, we'd have a whole new ecosystem of personal applications!
I wish I could change the name from Hyperclay to TiddlyApp :)
Thank you for your kind words, much appreciated, speaking as the creator/maintainer of TiddlyWiki. I really like what you've done, and the way you've described it on the site. I hope you will enjoy success with it, and have as much fun with it as I have with TiddlyWiki.
> If only browser vendors allowed their users to persist HTML files back to their own machines, we'd have a whole new ecosystem of personal applications!
The trick TiddlyWiki does with data URLs (IIRC?) (https://tiddlywiki.com/#Saving%20with%20the%20HTML5%20saver) seems pretty close to me.
I spent a weekend making a self-host twitter alternative.
source: https://github.com/est/gitweets/
demo: https://f.est.im/ (renders via github API)
Basically it renders its self git repo commit history as a feed timeline.
Never lose your data on microblogging service providers again! Clone the repo anywhere anytime, make tweets by "git commit --allow-empty".
Everything is placed inside a single-html.
How does versioning work? After you fork an HTML app, is there a way to update it and get newer features without manual intervention?
I'm thinking about the Kanban board example I saw in the demo video. It looks like column re-ordering wasn't supported yet. What if I fork the app, put time into creating my Kanban, then I want to update to a new version that supports column re-ordering?
I really like this. If you ever plan an AMI with this, deploying hyperclay on maybe a t3 instance, installing Node.js via the package manager (https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-...), and then setting up the Hyperclay server using npm to handle requests, I think a lot of startups could be users. Would it be fair to say that Hyperclay could offer a lean way to rapidly prototype and iterate on MVPs, like landing pages, dashboards, or user-feedback-driven tools, where frontend changes (e.g., A/B testing UI elements) automatically update the underlying HTML source for instant deployment??
If it was marketed to startups to reduce development overhead by eliminating separate build pipelines or servers, allowing small teams to focus on core features rather than infrastructure, definite winner. Not sure how much your into AWS but this made me think of an AWS partner we use HostJane could use Hyperclay to help bundle cost-optimized spot instances for testing (mainly tech startup clients - https://www.hostjane.com), then push out a seamless CI/CD via CodePipeline, global distribution through CloudFront, Hyperclay could enable clients to scale from proof-of-concept to production affordably while maintaining full control over their app's evolution without vendor lock-in. Potentially doing away with complex databases or backend frameworks... amazing, well done!
Nice… keep in mind there are already very mature tools like https://tiddlywiki.com/ which supports a plugin architecture.
Hitting "Request Access" on https://hyperclay.com/request-early-access with an empty field (no email provided) renders "Subscribed!".
I tried one of the demos and it didn't work; my changes were not persisted when I refreshed the page. I don't know how it's supposed to work, exactly, but a single self-contained HTML isn't it.
I too have an odd obsession with keeping everything in 1 file.
I recently (as an experiment) exclusively vibe-coded an Asteroids clone (with a couple of nifty additions), all in a single HTML file, including a unit test suite, which also works on either desktop or mobile: https://github.com/pmarreck/vibesteroids/blob/yolo/docs/inde...
Playable version (deployed via github docs) is here: https://pmarreck.github.io/vibesteroids/ Hit Esc to pause and see instructions (pause should be automatic on mobile; can re-pause by tapping top center area).
Type shift-B (or shake mobile device... you also would have had to approve its ability to sense that on iOS) to activate the "secret" ability (1 per life)
No enemy UFO's to shoot (yet) but the pace does quicken on each level which feels fun.
It doesn't update itself, however... (and I just noticed it has a test fail, and a test rendering bug... LOL, well at least the tests are valid!)
Doesnt really sound like an odd obsession - it's an AI workflow thing. Just copy-pasting everything.
I have an odd obsession with github repos that only have 1 file
This is a really cool idea. The use of custom attributes without `data-` before it makes me a little nervous. Is that a concern here? I saw `project` being used on elements and if that's officially used for something eventually can it muddy things up?
HTML5 is surprisingly lax about using arbitrary attributes and tags: any attribute or tag without a dash in it could potentially conflict with a future version of the spec, but it doesn't go out of its way to forbid them either. data-* attributes are special in that they appear in the .dataset property in the DOM, but anything with a dash should be future-proof against the HTML spec.
Very good. I was wondering why nobody did something like that before. At least this was my conclusion from my google searches few months ago. From a design perspective, I don't like storing state in the DOM itself, I would have find much more flexible to have the state in a json as a single source of truth and use reactive patterns such as state change => ui change and not hiting the DOM directly. That sounds like big framework things, but it saved me from acute headaches in a personal similar framework I did for self-contained apps. It was not HTML but I thought I would apply the same logic if I had to do it for html apps too.
I guess your searches missed Tiddlywiki. I think there have been a couple of other takes on the concept too.
Also our Webstrates (https://webstrates.net) system stores state in the DOM itself. But it's more a system for research prototyping than publishing web pages.
This is just awesome! But seems like a closed source project, and the pricing page returns HTTP 404.
Are there any open source alternatives like this? First time I hear about this idea. However, I can imagine it wouldn't take much effort to implement the basics. Chromium even has a design mode you can activate by typing `document.designMode='on'` in the console. Then you would just need to write a little javascript that handles auth, a save button, and a backend to persist the altered html.
There is an open source, local app version by the same author (me) here: https://hyperclay.com/hyperclay-local
fwiw, for this kind of tech - personal level projects - there is not a snowball's first summer outing in hell's chance I'm going to pay for someone else to host my thing remotely. I would like to just self host, and if it was good I would buy a license for it so I can self host - but I think you have a customer in mind that doesn't exist.
Your ideal customer a) is extremely technically proficient, such that they are even capable of finding this in the first place, and their brain doesn't glaze over at "jQuery is Your Starting Point" - the opening line of your docs. b) They for some reason would rather pay for someone else to do the world's easiest hosting job and deal with whatever baggage and limitations come with this.
Or am I misunderstanding? Like it's a nodejs server on some aws box. Charging people for this is fine, but not allowing them to do it themselves seems... ridiculous?
You gotta eat, I know, but I'm wondering who it is that is ok paying for someone else to do the easiest part what they do for a living.
I think you're underestimating the market here. It's not just extremely technically proficient people, it's the glitch people, the "custom myspace theme" people, possibly even the jsfiddle people.
The `/save` endpoint looks almost trivial. Knocking up a mimic wouldn't take much. The client libs will be interesting, but from the looks of things they're not quite there yet.
> You gotta eat, I know, but I'm wondering who it is that is ok paying for someone else to do the easiest part what they do for a living.
I don't think that hosting is necessarily "part of what they do for a living" for people who write the code.
There is no reference to its license model...
Sorry about that, it's fixed now: MIT License
Mavo seems pretty similar, saves to github, allows flipping the UI to admin/editor mode https://mavo.io/
I really liked this when it was launched and thought it had a great deal of potential when it launched. I think the main difference is that it's more focused on content-editing, not updating the code of the page itself.
Slightly tangential: a lot of my vibe coding experiments are standalone SPAs because I can't be bothered to set up a secure server (and I am too cheap to pay for it). I love that I can open my "mobile-first" apps directly from my phone's Downloads folder.
I have a feeling that a lot of these little tools people make with low-code vibe AI apps do not require more than a single HTML page with JS imports.
(I also suspect that there is a ton of duplication in what people create, but, of course, I have no data to back it up.)
This is really cool. About to try it out!
I build something along those lines as well. My problem was that I couldn't synchronize localStorage data, so I made htmlsync.io.
Here's a video of the creator explaining more
https://www.youtube.com/watch?v=OUiTBFDxwaM
Full disclaimer: I only scanned the article, but based on the title, SvelteKit does that with a single option "inline".
https://svelte.dev/docs/kit/configuration#output
How so? Can you describe what usecase that enables?
Very interesting.
Pricing page returns a 404 as of now, though.
https://www.hyperclay.com/pricing
This is great and all (I've been making my own standalone web app htmls), but one issue I've found when sharing with others is iOS (iPhone/iPads) don't support them. Apple ugh.
Any suggestions how to overcome this? I believe it's a security setting, not allowing localstorage to be set.
You can do that with htmlsync.io
The title reminds me of TiddlyWiki.
Reading that website was quite enjoyable. Simple scrolling and loved the look.
I have already moved most MVP to single file apps. This gives my intuition much more tools. Thanks for building this!
I am not sure how this proposal deals with the problem of templating. If you have a bunch of documents (say, blog articles) that should have a consistent layout, you are going to want to create a template for them. But then the document you see isn't the "true" document, and in order to save the content you're going to have to annotate it to "reverse" the templating.
If it does this, then it is very exciting indeed, but I could not see it.
I'm getting a 404 for most of the pages. Not confidence inspiring.
I wasn't planning to launch today hehe. The changelog and pricing links are fixed!
Very interesting concept.
I've imagined our internal claim cases to be standalone html pages, making them easily versioned for when new regulations come.
Simplicity is a good goal to have, and these guys have it.
Great name, cool idea and this guy communicates well. Inspiring to see!
The drag and drop on you personal dev blog seems very broken, or I'm an idiot
So you need a server for this to work and that server is closed source?
Is this a closed source project? I don't want to give my email address to get a chance to even try it.
How did it do safe version control efficiently?
This reminds me of a self contained svg editor running in the browser , that I wrote a few years ago.
I really like this idea, I envision something where this would be made possible on browsers now. This could only happen after further consideration about the security implications of localhost html files using secure context apis like indexeddb and localstorage The powers that be would rather turn this concept into a mArKetPlaCe -- Just let us create! Why must we always kneel before the altar of capitalism?
I experimented a bit with the concept to build my resume, I had naively been using gatsby a while back. "Just use a plain html file!" - It was a real "duh!" moment. You just edit the embedded markdown then viola. Want a pdf? Press cmd+P
https://github.com/rbbydotdev/resume
... I would like to up the anty and have web apps work in a portable vanilla HTML file WITHOUT needing a webserver to run it. E.g., double click and run. CORS be damned!
Webservers are a pain in the ass and a legitimate barrier to entry. Wouldn't it be great it you could literally send around a single file, especially to non-technical users who cant run a web server, to run your apps?
This is what people did before web apps. Package a binary and ship it to customers.
Problems with the approach: * Customers still ask you why stuff doesn't work, except now it's their hardware * Observability is not as strong on self-hosted solutions * There is no true universal binary, so no matter what you have to put constraints up (only runs on windows, mac, etc.) * Updates are way harder
Browsers are built to browse the web, trying to remove the web out of browser apps seems illogical
So:
1) it says it’s a vanilla HTML file but it needs a server running
2) it’s just a landing page that collects your email to give you “early access”.
I really wonder what this is doing on the home page.
It's even easier with Go + templ. You can compile a whole site into a single executable file, in the range of 20-30MB. Use sqlite with it and you've built yourself a portable and dynamic site capable of running almost anywhere in an instant. Use nginx load-balancing with a central sqlite if you need to scale
I've built some single-file HTML page tools at work that use newer Web APIs (WebSerial, WebUSB) and essentially utilize the browser as a cross-platform application virtual machine, which is a great way to think about browsers. With WASM compilation, Canvas, and WebSockets, combined with this self-modifying concept where an HTML file is a contained, stateful application that can persist, we've got very interesting possibilities for the future of user-facing applications, both local and fetched remotely. This is probably exactly what some of the visionaries at Google were thinking of when they concepted the Chromebook and Chrome OS.
> The coolest part? It's just an HTML file. Nothing special. Change it, it serializes its DOM, and sends it to a /save endpoint. Nothing magic about it.
*The tech: Hyperclay is a NodeJS server and frontend JS library*
So... it's not just an HTML file.
I for one, like the fun you had on the page. Ignore the haters. Only critique would be you should just explain how it works near the top. I think most devs myself included want to first understand what it is before the why it’s awesome.
ps. Way back there was a project called tiddlywiki that was a self modifying html file and was pretty popular. I think initially there was no way to save new version but to basically save the file to disk to either fork a file or replace itself.
> The first thing you should reach for is jQuery
And I'm out!
Honestly I was nodding along with the landing page. But including a dependency to an old timey JS library which is now largely unnecessary given new native web APIs? That seems contrary to the spirit of this project.
this falls down really quickly once you get past a couple MB worth of data, like trying to add images.
This is a nice idea; I am just not keen on having to host a nodejs server.
Now I am wondering whether the same thing could be achieved with just nginx & WebDAV?
Looks like your Kanban demo app is broken.
Wait until they find out about PHP. Mind blown.
Somebody's been reading The Oatmeal recently
(but seriously, very cool)
It's been too long! Off to The Oatmeal I go...
But depends on the whatng cartel web engines... Nothing to be proud of, mate.
no open source???? meh
If you use Claude to generate apps in the artifact they are very similar - self contained and easy to create and share.
You don't get localStorage persistence though.
Every time I see projects like this what I hear is: “I hate JavaScript, just use html and web standards (oh and a bunch of JavaScript but I hate JavaScript so let’s not talk about it much).”
I would love to have people try building these on https://RTCode.io
The playground has lots of unique features, CLI agent integration for AI to let you collaborate with Claude Code or Codex CLI, etc. You can deploy straight to https://RTEdge.net
The playground has HTML I ↔ O iframe with mostly reload-free 2-way IO sync, built-in service/edge workers with URL imports of ESM, and a whole lot more. You can see some examples under Code > New…
Here is a recent one for accessible multi-OS keyboard shortcuts: https://kbd.rt.ht/?io