←back to thread

578 points smusamashah | 3 comments | | HN request time: 0.407s | source
Show context
johnfn ◴[] No.42463936[source]
I think "single HTML file" sets up a certain expectation that a five-thousand-line long HTML file with ~3500 lines of embedded JS doesn't really live up to. I mean, hey, everything can be a single HTML file if you embed the bundle inline in your HTML!

Cool project, though - don't mean to take away anything from it.

replies(14): >>42464100 #>>42464173 #>>42464210 #>>42464396 #>>42464481 #>>42464520 #>>42464775 #>>42465102 #>>42466230 #>>42466423 #>>42466472 #>>42467609 #>>42472114 #>>42474653 #
rpdillon ◴[] No.42464173[source]
I totally understand your take, but as a guy that spends most of his time on side projects working on single HTML files, I have a different perspective.

I find the totally self-contained nature of them very appealing because it travels well through space and time, and it's incredibly accessible, both online and offline.

My current side project is actually using a WebDAV server to host a wide variety of different single HTML file apps that you can carry around on a USB drive or host on the web. The main trick to these apps is the same trick that TiddlyWiki uses, which is to construct a file in such a way that it can create an updated copy of itself and save it back to the server.

I'm attracted to this approach because it's a way to use relatively modern technologies in a way that is independent from giant corporations that want to hoover up all my data, while also being easy to hack and modify to suit my needs on a day-to-day basis.

replies(8): >>42464261 #>>42464741 #>>42465036 #>>42465064 #>>42466172 #>>42468502 #>>42468962 #>>42470850 #
1. sdeframond ◴[] No.42468962[source]
> The main trick to these apps [...] is to construct a file in such a way that it can create an updated copy of itself and save it back to the server.

Any additional info/pointers on this ?

replies(2): >>42469318 #>>42471443 #
2. ◴[] No.42469318[source]
3. rpdillon ◴[] No.42471443[source]
Yes, I have done a lot of analysis on the structure of tiddlywiki and featherwiki to figure out the right way to do this in a more repeatable way. And that's the basis that I'm using for the projects I'm working on. I'm planning to write a blog post on this soon because I've learned a lot. So stay tuned.

For the benefit of the Hacker News audience that are curious, let me take a stab here.

The general strategy is to include JavaScript in the HTML document that knows how to look at various nodes in the DOM and create a new version of the document that uses an updated set of data.

Some sections of the data can be pulled verbatim. So, for example, if you have one giant script at the bottom of the doc, you can give it an ID of perhaps S, and then use that ID to retrieve the outer HTML of that script tag and insert it into the clone.

Other areas of the DOM need to be templated. So for example, I insert a script that is of type JSON, and that contains all of the data for the application. This can be pulled and stringified when creating the clone.

For a minority of attributes like the title and document settings like whether or not you're in light or dark mode, you want to avoid a flash of unstyled content and so you actually templatize those elements so they are written into the cloned copy with the updated data directly inline.

There's no real magic to it, but it can be a little bit tedious. One really interesting gotcha is that the script tag is parsed with higher precedence than quote tags. And so I have to break up all script tags that appear in any string that I'm manipulating so that the parser does not close out the script I'm writing.

I have a very minimal app that uses this technique called Dextral. I'll be happy to host it on my site and link it here.