Comment by ninalanyon
1 day ago
> kage serve $HOME/data/kage/paulgraham.com
If the result is static why does it need a server? Isn't it possible to make it so that it can simply be opened by the browser? Like:
$ firefox $HOME/data/kage/paulgraham.com
Then the result would be useable on machines without kage nstalled.
You could use python -m http.server instead. I haven't tried it yet, but it should work.
Actually, Kage has two parts: a crawler that crawls pages and converts them to clean HTML by capturing the DOM after rendering in Chrome/Chromium, and a pack/serve component that packages the result as either a ZIM file for Kiwix or an executable file.
Usually JavaScript is blocked when you load pages that way.
Not all JavaScript, but a lot of APIs are restricted
I thought all the JS was stripper?
Since when? You won't be able to make HTTP requests to localhost, as it'd be a different Origin, but I don't think any mainstream browser blocks JS outright when you use file:// to load and view HTML files.
Somewhere around 2019, each document loaded from file:// became its own origin in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1500453 (I didn't check when this happened in Chromium)
Related WHATWG discussion: https://github.com/whatwg/html/issues/3099
4 replies →
I am quite familiar with this and it is factually false
Js modules don’t work on file urls (classic js does).
1 reply →
You’ll likely run into a ton of CORS issues doing that.
I don't think so, there is no HTTP requests being done from JS as it's stripped away, and all the other resources are pulled down (and I'm assume their reference made relative), so really shouldn't be any issues because of CORS at all.