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...
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.
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.
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.
> 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 ?
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?
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.
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?
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.)
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/
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.
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.
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.
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.
97 comments
[ 6.0 ms ] story [ 70.6 ms ] thread(but seriously, very cool)
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...
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.
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.
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 ?
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?
https://www.youtube.com/watch?v=OUiTBFDxwaM
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?
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.)
Pricing page returns a 404 as of now, though.
https://www.hyperclay.com/pricing
But in my experience the potential audience shrinks significantly once anything git related is expected from a user.
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.
https://en.wikipedia.org/wiki/HTML_Application
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.
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.
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.