Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hyperclay.com

Post reply on HN
Print view View original

191–200 of 240 posts

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

#191

Post by codedokode »

rmah wrote: post #153
jtbayly wrote: post #150

Earlier quoted context omitted.

This is so weird that a random website on a random server (having SSL doesn’t change that in the slightest) is considered less of a risk than a file I have on my own computer. Can somebody help me understand what’s going on?

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.

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

#193

Post by srcreigh »

jtbayly wrote: post #150
cluckindan wrote: post #104

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…

This is so weird that a random website on a random server (having SSL doesn’t change that in the slightest) is considered less of a risk than a file I have on my own computer. Can somebody help me understand what’s going on?

The rule was probably intended to block public non-SSL pages, so your clipboard data doesn't ever get sent over the wire unencrypted.

Why does it block local pages? Well what benefit of is to Apple or Google if it were easier to make good localhost webapps?

Try deleting Safari site data(indexed DB etc) for your localhost site. You won't be able to. Hell, even deleting data for a specific public site is hilariously painful. Try adding a certificate authority to your iPhone. Try playing locally cached audio blobs via web APIs on an iPhone. There's probably 1000 more.

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

#194

Post by mpyne »

notnmeyer wrote: post #182
hombre_fatal wrote: post #176

Earlier quoted context omitted.

How would TiddlyWiki write to filesystem (save) without a server? I thought opening index.html in the browser was basically just a demo.

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.

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

#196

Post by rlue »

calebm wrote: post #170
BoppreH wrote: post #35

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…

I'm still confused - if it requires a NodeJS server, then it wouldn't be a fully self-contained HTML file would it?

It technically doesn't say "self-contained", but it does say "portable" and "self-updating", which I must agree is misleading.

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

#197

Post by codedokode »

emadda wrote: post #139
codedokode wrote: post #101

I would like web standards have better support for pages stored in a local file (opened using file:// protocol). Sometimes I write simple HTML/Vue based mini-apps for myself and every time something doesn't work and I need workarounds, for example: - local HTML file cannot import local JS modules, so I have to use legacy writing style - local HTML file cannot open other local files (for example, audio files) I unders…

The local html file can read local resources via src=file_path attributes on html tags (img, audio, video, script etc). But the src-included files must be in the same directory as the root html file (or a descendant directory) I used this in my macOS app Pocket Log to output a local html audio log ( https://enzom.dev ).

Sadly it doesn't work for JS modules, only for legacy JS scripts.

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

#198

Post by amonks »

evbogue wrote: post #117
BoppreH wrote: post #35

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…

How does this differ from htmx?

htmx is a javascript library that reads configuration from html attributes and sends http requests based on that configuration

hyperclay is a web server that stores and serves versions of html files

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

#199

Post by saghm »

codedokode wrote: post #101

I would like web standards have better support for pages stored in a local file (opened using file:// protocol). Sometimes I write simple HTML/Vue based mini-apps for myself and every time something doesn't work and I need workarounds, for example: - local HTML file cannot import local JS modules, so I have to use legacy writing style - local HTML file cannot open other local files (for example, audio files) I unders…

> I understand that there is a risk if we allow local HTML files to access anything, but there should be some way - for example, a file or directory might have some suffix that allows access to it.

> I do not want to use a web-server because it feels like overengineering and I don't want to open a terminal, navigate to a directory and start a server every time, it takes too much time. I just want to type the URL and have my app running

I'd love for there to be an "offline only" mode for browsers where you can either access the local filesystem or remote pages, but not both. I don't think this would completely solve the use case you describe, since there would still presumably be circumstances where it would be helpful to reference something external, but it feels like it would be pretty useful to be able to use a browser as a limited server for static files, and it would be relative simple and intuitive compared to needing to have something in the files themselves indicate the intended semantics.

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

#200

Post by swiftcoder »

koolala wrote: post #162
swiftcoder wrote: post #94

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.

Could you put a token in a http auth username? Leave the password blank?

You could, but it's at the behest of the client, so browsers would have to implement that for it to be useful. If browsers are going to implement something, might as well come up with a decent standard.
Post reply on HN