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?
panphora · 25m ago
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)
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.
maelito · 2h ago
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...
aszen · 2h ago
From what I understood the html file itself is updated so it's updating forms, attributes and other tags to include the new changes
aszen · 2h ago
Then that file is posted to the backend for persistence
pavlov · 3h ago
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.
jauntywundrkind · 2h ago
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.
panphora · 23m ago
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.
esperent · 19m ago
> 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.
weinzierl · 2h ago
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.
doublerabbit · 1h ago
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.
dismalaf · 2h ago
> 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...
tommica · 2h ago
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?
reactordev · 27m ago
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.
leptons · 1h ago
>Firebug brought the concept to existence in the first place.
There were other browser "dev tools" before firebug.
Crazy - I had forgotten about the earlier ones! The IE one I used at some point, and fiddler too
sethaurus · 2h ago
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.
BoppreH · 1h ago
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.
panphora · 15m ago
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.
leptons · 1h ago
This all sounds like something from 2001. I was doing pretty much exactly this around 2001, using contenteditable with an IIS/JScript back-end.
BoppreH · 55m ago
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.
rbbydotdev · 1m 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
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.
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.
mcteamster · 56m ago
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.
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?
panphora · 5m ago
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.
clemensnk · 2h ago
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.
panphora · 2m ago
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.
Sammi · 1h ago
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/
KoolKat23 · 29m ago
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.
maelito · 3h ago
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 ?
> 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 ?
panphora · 31m ago
> 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.
general1726 · 3h ago
Or you will rename one page, instantly breaking URL pointing on that page on all already saved pages.
phantomathkg · 3h ago
At first I thought it is tiddlywiki but it is not.
sydbarrett74 · 1h ago
I'm getting a 404 for most of the pages. Not confidence inspiring.
dr_kiszonka · 2h ago
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.)
swiftcoder · 3h ago
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...
bapak · 2h ago
You mean HTTP auth?
oreilles · 2h ago
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.
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.
modeless · 3h ago
I guess your searches missed Tiddlywiki. I think there have been a couple of other takes on the concept too.
clemensnk · 2h ago
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.
tommica · 1h ago
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.
VagabundoP · 1h ago
Reading that website was quite enjoyable. Simple scrolling and loved the look.
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)
[0] https://hyperclay.com/hyperclay-local
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.
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.
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.
Isn't that basically Wikipedia? I can't imagine a much simpler system that could work at modern web scale.
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.
> 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.
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...
As a sidenote, does manipulating forms count as editing?
There were other browser "dev tools" before firebug.
https://www.otsukare.info/2020/08/06/browser-devtools-timeli...
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.
Note: we are working on a way for a developer to push "DOM-based schema migrations" to all forked apps.
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
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.
https://en.wikipedia.org/wiki/HTML_Application
But the ultimate goal is to have an ecosystem of where you can host/deploy/use HTML apps, including other competing services.
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...
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?
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.
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.
Any suggestions how to overcome this? I believe it's a security setting, not allowing localstorage to be set.
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 ?
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.
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.)
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...
Pricing page returns a 404 as of now, though.
https://www.hyperclay.com/pricing
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.
https://www.youtube.com/watch?v=OUiTBFDxwaM
(but seriously, very cool)