For those who don’t understand what it’s doing (like me at first):
You first have to host these index.html and sw.js on a regular server (or use the URL in the readme) and then this service will serve a folder of your choice directly from your computer.
This is if you ran your trusty Python server from the CLI, except you did it from the browser, with an unchangeable host:port
The folder will appear to be published from the server that hosts that sw.js file.
It is using HTTP, just doing it through browser APIs[0][1] so in this case the server layer is the service worker but it's still happening through HTTP means. So the client and the server are both running in the browser, the only difference is that this "virtual" server can only be accessed by the same browser session. They are very powerful APIs as you can intercept the network layer and do all sorts of hacks, like the OP's project.
Not the same. Disk files can be browsed via HTTP (HTTPS), so you can preview a local static site directly, without tools such as http-server, SimpleHTTPServer, etc.
Service worker file loader != HTTP server. You are intercepting requests which are usually fulfilled by HTTP, but you are not implementing or interacting with HTTP.
Genius! I feel the File System Access API[0] has a lot of potential in bringing data ownership back to the users (instead of being held by some server) but it's very under-utilized atm.
You mean the .mp4 in the README? It seems like it's just a plain link inside the README.md that GitHub previews/displays. Didn't know it did that. The link is:
You first have to host these index.html and sw.js on a regular server (or use the URL in the readme) and then this service will serve a folder of your choice directly from your computer.
This is if you ran your trusty Python server from the CLI, except you did it from the browser, with an unchangeable host:port
The folder will appear to be published from the server that hosts that sw.js file.