This week's #WebOrigami comic: Pagination
More about Origami Tree.paginate builtin function: https://weborigami.org/builtins/tree/paginate.html
HTML comic: https://weborigami.org/comics/pagination.html
This week's #WebOrigami comic: Pagination
More about Origami Tree.paginate builtin function: https://weborigami.org/builtins/tree/paginate.html
HTML comic: https://weborigami.org/comics/pagination.html
๐๐น๐๐ฟ๐ฟ๐:
https://thewhale.cc/posts/1765835666-blurry
A low-configuration static site generator in Python with a focus on SEO and page speed.
The one header I didn't add yet: CSP.
For sites that render untrusted input it mitigates an active surface. For a static site it guards against rarer-but-bigger events: a compromised analytics script, a poisoned CDN, a future change that adds an input path.
Astro 6 added an integration for what it emits; iframes, external fonts, and third-party services stay manual. Will inshallah follow when the audit fits.
Skipped Permissions-Policy on the static site.
It disables browser APIs (camera, mic, geolocation) the site doesn't use. Disabling something you're not using doesn't protect you from anything.
Embedding YouTube with fullscreen would also mean carving exceptions back in. More config for zero gain.
The scanner score drops one notch. The site is no less safe.
A bit inside baseball -- how I made my blog faster: cut CI per push from ~6 min to ~2 min, and kept every home/archive page O(1) in corpus size. Principles: compute once at input-change time, put the result under a stable URL, let everything downstream pull it from cache.
https://benjaminhan.net/posts/20260511-site-efficiency/?utm_source=mastodon&utm_medium=social
This week's #WebOrigami comic: Track changes in your site
More about Origami's Dev.changes builtin: https://weborigami.org/builtins/dev/changes
HTML comic: https://weborigami.org/comics/track-changes-in-your-site.html
This Origami tool works with any #staticsite generator!
Most cache misconfiguration is not carelessness, it's a missing handshake.
Your build encodes assumptions: hashed filenames mean the URL changes whenever the content changes. The web server has to know that, or the assumption stays unused.
If the config doesn't reflect what the build produces, the framework's work gets quietly undone at the last layer of the chain.
Your site loads. From the outside it works. But: do returning visitors re-download everything on every click? Can the connection be downgraded from HTTPS to HTTP on public WiFi? Does your homepage count as one site in Google's eyes, or two?
For most static sites: no, yes, and yes. The web server config is the last layer most setups never touch.
Been working on tweaking an old Chromebook to run smoothly on Linux, and trying to get up and running with a static site, which will bring me fully into the #IndieWeb world.
Hate to admit it, but the SSG has me a little perplexed. It's not as "quick and dirty" as I was led to believe. #staticSite #Linux
Show HN: Notion-to-site โ sync any Notion database to local Markdown/MDX/JSON
Notion-to-site๋ Notion ๋ฐ์ดํฐ๋ฒ ์ด์ค๋ฅผ ๋ก์ปฌ Markdown, MDX, JSON ํ์ผ๋ก ๋๊ธฐํํ๋ ์คํ์์ค ๋๊ตฌ์ ๋๋ค. Super.so ๊ฐ์ ์ ๋ฃ ์๋น์ค์ ๋์์ผ๋ก, ์ฆ๋ถ ๋๊ธฐํ์ ์์, ๋๊ธฐํ ๋ธ๋ก ๋ฑ ๋ชจ๋ Notion ๋ธ๋ก ํ์ ์ ์ง์ํฉ๋๋ค. ์ด๋ฏธ์ง ๋ค์ด๋ก๋ ๋ฐ WebP ๋ณํ ๊ธฐ๋ฅ๋ ํฌํจํ๋ฉฐ, Next.js, Astro, SvelteKit ๋ฑ ๋ค์ํ ํ๋ ์์ํฌ์ ํธํ๋ฉ๋๋ค. AI ๊ฐ๋ฐ์๋ค์ด ๋ฌธ์ํ ๋ฐ ์ฝํ ์ธ ๊ด๋ฆฌ ์๋ํ์ ํ์ฉํ ์ ์์ต๋๋ค.