Live data from Hacker News

Web apps in a single, portable, self-updating, vanilla HTML file

hyperclay.com

1–10 of 240 posts

Re: Web apps in a single, portable, self-updating, vanilla HTML file

#3
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...

Re: Web apps in a single, portable, self-updating, vanilla HTML file

#5
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.

Re: Web apps in a single, portable, self-updating, vanilla HTML file

#6
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.

Re: Web apps in a single, portable, self-updating, vanilla HTML file

#7
post #6

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 bi…

I guess your searches missed Tiddlywiki. I think there have been a couple of other takes on the concept too.

Re: Web apps in a single, portable, self-updating, vanilla HTML file

#9
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 ?

Re: Web apps in a single, portable, self-updating, vanilla HTML file

#10
post #9

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…

Or you will rename one page, instantly breaking URL pointing on that page on all already saved pages.
Post reply on HN