3 ms·

> 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

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

doctoboggan 4mo ago
Usually JavaScript is blocked when you load pages that way.
- pixelatedindex 4mo ago
  I thought all the JS was stripper?
- embedding-shape 4mo ago
  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.
  - rzzzt 4mo ago
    Somewhere around 2019, each document loaded from file:// became its own origin in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1500453 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 https://github.com/whatwg/html/issues/3099
    - embedding-shape 4mo ago
      Yeah, but that's fine, the document is .html, and it can load ./app.js or ./style.css just fine even if loaded by file:// (as long as it isn't initiated by JS itself, then Origin starts to matter a lot more), otherwise basically every single local HTML file would suddenly be broken, I don't think anyone would have accepted that even with the origin changes.
      - dncornholio 4mo ago
        React and Angular are completely broken through file://
        embedding-shape 4mo ago
        I don't know about Angular but React works perfectly fine through file://. I'd think the bundler/packager matter more than whar JS libraries you use, you sure you're not actually thinking of something else not handling file:// properly?
      - rzzzt 4mo ago
        I tried this on a small example and it works indeed. In my head this would have been something like a restrictive CSP script-source directive, even if not exposed in response headers or anything.
        embedding-shape 4mo ago
        > I tried this on a small example and it works indeed. I was thinking "of course it works, how else would people get started creating websites otherwise?" then I remember what's the most common approaches in the frontend ecosystem nowadays. Back in the days of yore, every tutorial/book started with "First we create a index.html file which you open in your browser ...", even a JavaScript resource would start with this of course :)
        rzzzt 4mo ago
        Weeellll those tutorials span a ~30 year time range now :) AMPP stacks and Python's built-in HTTP server was available most of the time if you needed to get away from the file:// protocol. The protection mechanism was introduced so that malicious saved pages can't just grab things from your Downloads folder and send stuff it to an attacker's server. But the method turned out to be a bit more refined than I have imagined: you can display an image but can't grab the pixels, run a script but not inspect its source code, fetch() will be unavailable, etc.
- dmazzoni 4mo ago
  Not all JavaScript, but a lot of APIs are restricted
- recursive 4mo ago
  I am quite familiar with this and it is factually false
  - danielheath 4mo ago
    Js modules don’t work on file urls (classic js does).
    - recursive 4mo ago
      They can be made to work with blob urls. I have done this.
      - danielheath 4mo ago
        Okay that’s super interesting and I would love to see an example or writeup - I have a project which would benefit from being able to do that.
        recursive 4mo ago
        It's a technique I created (someone else must have done it first??) for a sandbox demonstrating a web UI framework I made. https://mutraction.dev/sandbox https://mutraction.dev/sandbox To see it work, click "Download self contained .html" from the menu. Here's the source file that handles this part: https://github.com/tomtheisen/mutraction/blob/master/mutraction-sandbox/src/selfContained.ts https://github.com/tomtheisen/mutraction/blob/master/mutract... The idea is to use <script type="inline-module" name="foo">...</script> to define modules. That's something I just made up. For each such script, provision a blob URL. The main blocker is usually the same origin policy. Crucially, these blob URLs count as the same origin. So then you need to rewrite the imports from the named modules to the blob URLs. I used some regex rather than a proper parser, but it was more than good enough for me. It seems quite doable to make some proper bundling tools around this concept.
afavour 4mo ago
You’ll likely run into a ton of CORS issues doing that.
- embedding-shape 4mo ago
  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.
tamnd 4mo ago
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.

doctoboggan 4mo ago

Usually JavaScript is blocked when you load pages that way.

pixelatedindex 4mo ago
I thought all the JS was stripper?
embedding-shape 4mo ago
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.
- rzzzt 4mo ago
  Somewhere around 2019, each document loaded from file:// became its own origin in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1500453 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 https://github.com/whatwg/html/issues/3099
  - embedding-shape 4mo ago
    Yeah, but that's fine, the document is .html, and it can load ./app.js or ./style.css just fine even if loaded by file:// (as long as it isn't initiated by JS itself, then Origin starts to matter a lot more), otherwise basically every single local HTML file would suddenly be broken, I don't think anyone would have accepted that even with the origin changes.
    - dncornholio 4mo ago
      React and Angular are completely broken through file://
      - embedding-shape 4mo ago
        I don't know about Angular but React works perfectly fine through file://. I'd think the bundler/packager matter more than whar JS libraries you use, you sure you're not actually thinking of something else not handling file:// properly?
    - rzzzt 4mo ago
      I tried this on a small example and it works indeed. In my head this would have been something like a restrictive CSP script-source directive, even if not exposed in response headers or anything.
      - embedding-shape 4mo ago
        > I tried this on a small example and it works indeed. I was thinking "of course it works, how else would people get started creating websites otherwise?" then I remember what's the most common approaches in the frontend ecosystem nowadays. Back in the days of yore, every tutorial/book started with "First we create a index.html file which you open in your browser ...", even a JavaScript resource would start with this of course :)
        rzzzt 4mo ago
        Weeellll those tutorials span a ~30 year time range now :) AMPP stacks and Python's built-in HTTP server was available most of the time if you needed to get away from the file:// protocol. The protection mechanism was introduced so that malicious saved pages can't just grab things from your Downloads folder and send stuff it to an attacker's server. But the method turned out to be a bit more refined than I have imagined: you can display an image but can't grab the pixels, run a script but not inspect its source code, fetch() will be unavailable, etc.
dmazzoni 4mo ago
Not all JavaScript, but a lot of APIs are restricted
recursive 4mo ago
I am quite familiar with this and it is factually false
- danielheath 4mo ago
  Js modules don’t work on file urls (classic js does).
  - recursive 4mo ago
    They can be made to work with blob urls. I have done this.
    - danielheath 4mo ago
      Okay that’s super interesting and I would love to see an example or writeup - I have a project which would benefit from being able to do that.
      - recursive 4mo ago
        It's a technique I created (someone else must have done it first??) for a sandbox demonstrating a web UI framework I made. https://mutraction.dev/sandbox https://mutraction.dev/sandbox To see it work, click "Download self contained .html" from the menu. Here's the source file that handles this part: https://github.com/tomtheisen/mutraction/blob/master/mutraction-sandbox/src/selfContained.ts https://github.com/tomtheisen/mutraction/blob/master/mutract... The idea is to use <script type="inline-module" name="foo">...</script> to define modules. That's something I just made up. For each such script, provision a blob URL. The main blocker is usually the same origin policy. Crucially, these blob URLs count as the same origin. So then you need to rewrite the imports from the named modules to the blob URLs. I used some regex rather than a proper parser, but it was more than good enough for me. It seems quite doable to make some proper bundling tools around this concept.

afavour 4mo ago

You’ll likely run into a ton of CORS issues doing that.

embedding-shape 4mo ago
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.

tamnd 4mo ago

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.