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!
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.
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 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.
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.
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.
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.
> 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.
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.
