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...
51–60 of 240 posts
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...
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 aut…
This all sounds like something from 2001. I was doing pretty much exactly this around 2001, using contenteditable with an IIS/JScript back-end.
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 t…
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 modificati…
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.
Any suggestions how to overcome this? I believe it's a security setting, not allowing localstorage to be set.
Earlier quoted context omitted.
> 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...
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?
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 choos…
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)
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 HT…
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.
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 t…
There is an open source, local app version by the same author (me) here: https://hyperclay.com/hyperclay-local
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 HT…
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.
Isn't that basically Wikipedia? I can't imagine a much simpler system that could work at modern web scale.