Live data from Hacker News

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

hyperclay.com

201–210 of 240 posts

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

#201

Earlier quoted context omitted.

No, specifically not. I don't want to store your username and passwords in a database (and then deal with account recovery, password rotation, etc) - I want identity . The browser should be able to vend me an (opaque, anonymous) token that identifies you as an individual. If your mobile and desktop browser vend the same token, then the website sees you as having the same identity on both platforms.

The privacy implications of this are a deep and toxic swamp into which every previous attempt has sunk. Right now, control over an email account is the best we've got.

> Right now, control over an email account is the best we've got.

And it's a poor enough solution that we have to build extra layers around it (for example, Apple's auth "login with Apple ID", which lets you hide your real email address behind an anonymous relay)

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

#202
post #194

Earlier quoted context omitted.

iirc browsers used to allow direct filesystem access.

They never did, if anything it's the opposite in that I think there are now APIs that can make this possible. With TiddlyWiki you had to essentially File -> Save As and save the HTML back over itself. There were other ways too but they were all workarounds to the issue that browsers don't allow direct access.

They did back around 2008. I used Wiki on a stick - see https://stickwiki.sourceforge.net/which was kind of neat) but after a few years, Chrome etc stopped letting it save itself.

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

#203
post #137

Earlier quoted context omitted.

A significant hindrance for generator-type apps is that only pages loaded via HTTPS have access to the clipboard API, so ”copy to clipboard” does not work via file:///. You can have a zero-build zero-dependency offline-only app which users could theoretically just save as a page, but copy buttons will not work, so you have to detect the API not being available and replace buttons with popover textareas. Clunky. As fo…

Chromium based browsers treat localhost as a secure context, so HTTPS isn't required to access APIs like the clipboard, web serial, etc.

Is that a recent development? It was not so a couple years ago, at least not when a non-80 port is specified.

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

#204
post #42
post #37

Earlier quoted context omitted.

>Firebug brought the concept to existence in the first place. There were other browser "dev tools" before firebug. https://www.otsukare.info/2020/08/06/browser-devtools-timeli...

Crazy - I had forgotten about the earlier ones! The IE one I used at some point, and fiddler too

I still use Fiddler. I prefer it to browser inspector network tab when I need to get into the weeds. It does so much, and I can write custom proxy tweaks with Javascript (actually JScript.NET, but works just like good old JS), and it works with other software, I use it with NodeJS all the time. It's like the Swiss army knife of HTTP.

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

#205

This is great and all (I've been making my own standalone web app htmls), but one issue I've found when sharing with others is iOS (iPhone/iPads) don't support them. Apple ugh. Any suggestions how to overcome this? I believe it's a security setting, not allowing localstorage to be set.

You can do that with htmlsync.io

Thank you, I'll take a look.

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

#206
Hyperclay is really cool. I love the idea of making edits persist right in the DOM. I hacked on something in a similar spirit called Dominique https://rebeling.github.io/dominique/?edit=1 no backend/frontend separation, just “one-end.” It’s more about playful editing with AI support (click anywhere and change text/structure instantly), whereas Hyperclay goes deeper with persistence and versioning. Fun to see, thanks for sharing!

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

#207
post #153

Earlier quoted context omitted.

The random website cannot access arbitrary files on your computer's file system and send it somewhere else. An html file with javascript running locally, if trusted, on a typical personal computer could do that.

There should be some way to mark files as accessible, for example, place them into a folder with a specific name (like "html-accessible-files") on the same level as HTML file.

Internet Explorer in an ancient age used to have .HTA ("HTML Application") files for a double-click a self-contained HTML file that can act as a small local application. It did a lot of what PWAs are still trying to do, somewhat more effectively and simpler. (.HTA was mostly just a ZIP file! Simple to build.) It also had a lot of security holes that gave it a terrible reputation and a lot of reasons it got killed. (It was very early days for "AJAX" and modern browser security tools like CORS and whatnot, after all.)

Such things seem to be cycles.

Today a lot of browsers support .MHT which is a similar format, but also worse in many other ways. (The M stands for MIME and wrapping a website like an email seems somehow sillier and weirder to me than wrapping it in a ZIP file, though I get that MIME wrappers are ancient internet tech with an ancient track record.)

Then we see all the millions of apps in PWAs and Electron downloads.

At some point it feels like we should have better solutions and cut some of the gordian knot cycling between "local apps are too much of a security risk" and "local apps should be complicated collections of Service Workers to get offline support" and "local apps should just embed a full browser and all its security implications/risks rather than allowing browsers to directly open local apps" and back and forth. .HTA and .MHT both showcase possible directions back to "simpler" than PWAs/Electron, they just have such fascinating and weird histories.

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

#208
post #116

Earlier quoted context omitted.

Thanks. Author mentioned TiddlyWiki as inspiration. But the whole point of TiddlyWiki was that it doesn't need a server right? So I'm trying to understand the difference, the payoff. I understand that local web APIs are ass and you very quickly run into the need for a server. But I'm wondering about the utility of combining the two approaches. It seems like a contradiction in terms. Here's a server to help you with y…

Turns out, the original TiddlyWiki used a java jar to handle the file persistence. (I remember it being so magically automatic, but recently investigated how it was done)

I don't think that's right - IIRC it used to be possible to write out a file, if loaded from a file:// URL, directly from JavaScript. Then that ability got nobbled because security (justifiable) without properly thinking through a good alternative (not justifiable). I mourn the loss of the ability, TiddlyWiki was in a class of its own and there should have been many more systems inspired by its design. Alas.

ETA: Wikipedia has reminded me the feature was called UniversalXPConnect, and it was a Firefox thing and wasn't cross-browser. It still sucks that it was removed without sensible replacement.

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

#210

Been doing something similar with save files for my game. Line 1 is " const rawData =" and line 2 is all the state. 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...

I keep this bookmark in Chrome which lets me open an editor in a tab and Chrome maintains the state of the textarea even through reboots as long as you don't close the tab:

data:text/html,Notepadhtml,body{margin:0;padding:0;}textarea{padding:10px;font-family:Courier;font-size:16px;height:100%;width:100%;border:none;outline:none;}document.getElementsByTagName('textarea')[0].focus()

Post reply on HN