* To serve content that can be accessed on networks using captive portals
* To serve content on localhost while developing
* To serve content on devices where setting up letsencrypt or other SSL is either too much of a hassle or not important
* To stand up a quick HTTP server on hacked servers
This is my use case, serving homeserver stuff from a ".internal" domain, only accessible through WireGuard. I ain't gonna mess with a custom CA just for this.
If one of my devices gets compromised enough to be able to sniff network packets that pass through the WireGuard interface, I have bigger problems to worry about.
It includes "builtins" for accessing other resources (i.e., as a client) using HTTP, but I hope it should be obvious why that is a necessity.
Reverse proxies have existed for a very, very long time, you simply run a local HTTP server and you let the reverse proxy take care of https-to-and-from-the-WAN-side part. Even in dev context, that takes at most a few minutes to set up these days thanks to letsencrypt's certbot.
- Because I want to
Not everything is security sensitive. Some information is entirely public and has no need for encryption. While SSL is also provides protection against man in the middle attacks, which helps you to trust that the information you are reading has not been compromised and altered, this is also a security requirement that just doesn't exist in a lot of use cases.
So yeah, private internal networks where information security just isn't a requirement because the information is not at all sensitive and nothing bad will happen in a worst case scenario ... don't force things on people that don't require those things.
I can sort of understand the rationale for web browsers pushing encryption for public websites, with the amount of ecommerce that happens in current year. But if your use case doesn't fall into that bucket, and if you've done your own risk analysis and came to the conclusion that you don't need encryption for what you're doing because nothing bad can possibly happen then there's no need to jump through the hassle of setting up certificates.
So you need to learn HTML and CSS so you can use Origami to... avoid building a site with HTML and CSS?
I think a better description of the project is that it's built around its async-tree abstraction: https://weborigami.org/pattern/
The audience you're left with (programmers) will bristle at the DSL and wonder why they don't just use "___" <-- fill in their favorite SSG.
And, I have my own take on it.
My static site generator Svekyll (https://extrastatic.dev/svekyll/svekyll-cli) has an option you can add to the _config.yml: "view_source"
If you do that, it provides a link at the bottom of each post which says "view source to this post" If you click on that, you can see all the files used to generate that post, and then download a zip which is a fully packaged tiny svelte app that builds into that blog page.
For example, this blog post on embeddings has a bunch of svelte components, embeds an embedding model right inside the page and runs it via JavaScript. If you scroll all the way down, you can download the zip file, unzip it and run "npm i && npm run build && cd build && npx http-server -o" and you can see the fully built blog.
https://webiphany.com/2024-04-29-distance-sean-shawn
PRs describing this feature:
https://extrastatic.dev/svekyll/svekyll-cli/-/merge_requests... https://extrastatic.dev/svekyll/svekyll-cli/-/merge_requests... https://extrastatic.dev/svekyll/svekyll-cli/-/merge_requests...
I dare say it's not that difficult for a programmer to roll their own SSG with whatever is at hand.
Does it have any clever properties that naive solution wouldn't?
* Like reproducible builds or incremental/cacheable builds?
* Does it require the entire site fits in memory at build time, or can it generate terabyte-sized sites without breaking a sweat?
Best to keep it simple to let any complex needs arrive on their own, instead of prematurely complicating things.