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!
Readit Newspanphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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 :)
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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.
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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.
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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.
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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 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.
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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.
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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)
panphora commented on Web apps in a single, portable, self-updating, vanilla HTML file hyperclay.com/... · Posted by u/pil0u
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.