#ssg

And it's done Yesterday I finally launched my migrated new blog. I moved it from slop'py hugo to the Zine SSG. Page: https://lukasrotermund.de Code: https://forgejo.lukasrotermund.de/lrotermund/blog-zine Zine is not yet v1.0, so it's not polished in every aspect. But I had a lot of fun during the migration! The new site is a lot simpler the the hugo blog. No more shortcodes, no more partials, no more themes, no JS. I have to patch a few more things and I have to find a way to add a site map, but all in all I am very happy. Check out Zine SSG! #Zine #ZineSSG #WebHosting #WebDevelopment #Development #Blog #Blogging #SSG #Hugo #Gohugo #FckAi #FckLLMs

I've posted a video about how you can build a site from scratch in any #programming language you like without the need for an off-the-shelf static site generator (#ssg): https://www.youtube.com/watch?v=6t3BN3Z-TkE&t=1147s This compares using an SSG like #Astro or #Eleventy (#11ty) to build a blog with building the same blog in #Python, #JavaScript, or even a language like #Zig. I'm designing #WebOrigami to be the most concise and clearest language for this purpose — but you can use any language you like.

The Blog Option in littleFedi ...and yes, this is build and served by the Raspberry Pi Zero W, powered by NetBSD https://rpi0w.stefanomarinelli.it/@stefano/blog/691cb62e-e7a1-434b-ba65-d059ee58ac41/ #NetBSD #littleFedi #Fediverse #SSG #Blogging #OwnYourData

The Blog Option in littleFedi littleFedi, like many social platforms, had both a strength and a limit. Posts, by their nature, are ephemeral. They get published, federated (unless local-only, which littleFedi handles) and then, over time, lost. Partly through self-deletion, partly through their normal blending in with the thousands of other posts that pile up over time. Sometimes, though, we want something to stay. And not just stay as a social post, but as an actual blog. A bit like with BSSG, I had thought it would be convenient to have a minimal system. Not to compete with WordPress or other solutions, but to have a small blog, integrated into littleFedi, that would produce and serve a blog updated every now and then, whenever the person writing felt like doing it. And that's why the blog option was born. The idea is simple: when you write a post, from the web UI or from the CLI, there's a checkbox, "blog post". If you check it, that post stops being just a status that will scroll past and disappear. littleFedi renders it into a real static site. No JavaScript, just HTML and CSS, an Atom feed, tag pages, a chronological archive. Nothing exotic, nothing that needs maintenance five years from now. The blog isn't a parallel system you have to feed separately. It's not an export, not an import, not a bridge to some other CMS. The post you wrote is the blog post. Same database, same act of writing, still boostable, still repliable, still part of the conversation on the fediverse side. The blog is just a second representation of the same content, generated automatically. Every time you create, edit, or delete a blog post, the whole static site for your account gets rebuilt from scratch, and the new version replaces the old one atomically, so nobody ever lands on a half-built page. If the build fails, the previous version stays in place. Simple, but it has to work reliably, or the whole idea is pointless. That's the core of it: two representations of the same post. As a status, it lives in the fediverse, interactive, part of the conversation, subject to replies and boosts like anything else. As a static page, it lives on the web, durable, indexable, with a permalink, something an RSS reader can hold onto. You don't have to decide in advance which posts deserve to last. You write normally, and if something turns out to be worth keeping, you flag it, and it gets its own page. One detail I cared about while thinking this through: the generated site has to be self-contained. When littleFedi builds it, media gets copied or hard-linked into the generated directory - images, audio, video. If it's stored on S3, it keeps its public URL directly. Either way, the point is that the site on disk doesn't depend on the instance staying up. If the server goes down tomorrow, the blog files are still a complete, working website. That wasn't an afterthought, it was one of the requirements from the start. Not every account gets a blog, and that's intentional. The instance admin has to enable the feature globally ([blog] enabled = true), and then grant it per account. It's not meant to be a CMS, and I didn't want it to become one. Blog posts can't be replies, can't be boosts, have to be public and top-level. These are constraints, not missing features: the blog is for your own writing, not for threads or reshared content. There's no JavaScript anywhere in the generated site. That was deliberate too. It loads fast, it works offline if you cache it, and it will still render correctly in ten years without anyone having to update a dependency. In the end, the blog option doesn't ask you to choose between writing socially and writing something permanent. You keep writing the way you always do, on littleFedi, and if a post is worth keeping, you check a box. No separate platform, no migration, no vendor lock-in. Just your own posts, some of them rendered into a small static site you can host anywhere, built out of something that already existed on the open web. Remember: all this is being currently served by a Raspberry PI Zero W powered by NetBSD Here's the result: https://rpi0w.stefanomarinelli.it/@stefano/blog/691cb62e-e7a1-434b-ba65-d059ee58ac41/ #littleFedi #SSG #BSSG #OwnYourData #Blogging #Fediverse #NetBSD

Sculpin 3.3.0 is available now! Sculpin is a PHP-based static site generator that allows you to write your website's content in Markdown, which is then rendered to static HTML that can be uploaded to nearly any web host. You can even get free hosting from GitHub Pages or Forgejo/Codeberg Pages. https://blog.sculpin.io/2026/07/19/sculpin-returns/ #smallWeb #indieWeb #blogging #StartABlog #php #markdown #staticSite #ssg

Folks, I've done it again. I've created a new static-site generator. Actually an #SSG starter that I extracted from my website's SSG so that I can use it to build new blogs for my other projects without being bogged down with the details specific to my website. If any of you fancy writing your own SSG in #Haskell, give it a go: https://abhin4v.github.io/shake-blog/ Shake Blog is meant to be forked and extended. It comes with a basic set of features: posts, pages, tags, archive and feed, which may be enough for you. But the main idea is to understand it and extend it for your website according to your requirements and taste. It uses #Shake, #Pandoc and #Mustache beneath, and comes with dark mode and code highlighting support. It includes a Github Action to build and publish your blog directly on Github pages with zero friction. Try it out and let me know. Boost to make me famous. #programming #blogging

Looking at Marmite as a static site generator, and being dismayed that it's shockingly easy to get it installed, set it up, and learn how to use it, because now I have to actually do the work of creating the content. Why didn't somebody warn me? #marmite #ssg #FOSS

Announcing BSSG 0.41.0 Caching is now working, several fixes are in and you can now hide the header menu, the estimated reading time and other things. https://blog.bssg.dragas.net/2026/06/14/announcing-bssg-0-41-0-several-improvements/ #BSSG #SSG #Bash #OwnYourData

Preparing the imminent release of BSSG 0.41.0 #BSSG #SSG

Static websites are the future. Not every site needs to be dynamically generated. Having a #blog served by a complex CMS like WordPress feels unnecessary after using #11ty . Compute is growing in cost and becoming scarce. Why waste it on sites suited for static generation? Plus, who wants to host a server with a database, a CMS, a bunch of plugins and all the security headaches that comes with it? #SSG #IndieWeb #Blogging

The early Web had a quality that has been lost ever since: it was *simple* Download #httpd , #netscape write some #html by hand and boom, the concept of a networked digital society is born. It first started going pear shaped with #LAMP . The complexity of a full blown database was not justified for most use cases. As proven decades later by the popularity of #sqlite and #ssg approaches. The final blow was when #bigtech got into the act. Immense complexity for the simplest things became a moat