I'm not sure I'd advocate for writing a static site generator, although I'm certainly guilty of writing a few myself.

Instead I always encourage people who are trying to start blogging to do the writing first. Figure out a workflow that works for you - what time of day you prefer writing, what editor, do diagrams naturally come up in your thought stream, etc. It's way easier to get this workflow dialed in when you're doing things locally since the switching cost between solutions is that much lower.

Only when you know that you A) enjoy writing and B) have something worth sharing should you invest the time in translating your workflow to something that can deployed. That might mean writing your own SSG - that might mean just spinning up a wordpress blog.

It's a fun project to try out new tech, but you have to acknowledge that you're doing it for fun rather than any sort of necessary reason. It's like when you build a game engine and never get around to doing the hard part: building the game.

It's a procrastination time hole that mostly just distracts us from the harder, less concrete, less fun thing we supposedly set out to do in the first place. It keeps us from shipping real shit.

e.g. Quit dicking around with your SSG and write the damn blog post already. The hard part of writing something worth reading is not your tech stack.

> [...] but most importantly you have to architect your website to match what the framework expects.

I guess that's what a framework is about. You get some abstractions that make your life easier and you pay by buying into the concepts.

> [...] some friends I've talked to where still on Next.js 12 and really felt the pressure to upgrade to not fall behind even more.

If the current version is doing its job, why update? It's a SSG not a browser that connects to the internet.

So I disagree. I'll not write my own and keep the existing one as long it's not too much hassle.

For over 2 decades, my personal Web site has been generated from one big Emacs Lisp file (plus a filesystem tree of image and downloadable files).

Both the code and the text data were in the one file.

The code included features like rich syntax coloring source view of files (fairly unusual at the time) that were also downloadable, and calendar-based blog navigation.

Over time, the code changed a little, such as to convert from HTML tables to CSS with the same look.

Just the one file, in Emacs, was a very rapid and lightweight way to work. Imagine a code file that includes simple function definitions, like that below, and calls to those functions, passed a mix of static and generated data for the pages.

    (defun web5-write-html-file-format-sideheads
        (root-dir subdir leaf-fname title-list sections)
      (if (stringp title-list)
          (setq title-list (list title-list)))
      (web5-write-file root-dir
                       (concat subdir "/" (or leaf-fname "index.html"))
                       (web5-page-html title-list
                                       (web5-format-sideheads title-list
                                                              sections))))

If I were doing it today, I'd probably do lots of Markdown files and a bespoke generator program, though that wouldn't be quite as rapid to develop as the Emacs single file one was.

> Plus, you get to choose your own stack. Want to write your content in AsciiDoc? No-one can stop you!

I wrote a static site generator once. I used a Makefile and m4 macros!

Yes, it's true: nobody could stop me. It's much more debatable whether the "you should" part applies. I was just trying to get some common header and footer HTML into all pages of a site and do it with tools that were already installed on the hosting provider's machine.

It worked. For some reason, the person who took over the site after me did not follow in my footsteps and keep using m4.

> it's way more work than using something that already exists. But it's also so much more fun.

I'd say this person "gets it". We spend waaay too much time bickering about what people "should" do, in my opinion.

I used various SSGs for a while but the SSGs kept having arbitrary breaking changes that took a while to debug. I switched to my own little Python script 6 years ago and have slowly evolved it since then. Hasn't broken yet.

Call me crazy, but for my blog I just write HTML and RSS manually in a text editor.

I've written two static site generators... well one of them has a full blown UI (drag and drop, side panels etc), the other is a command line tool.

For the WYSIWYG tool I used craftjs and lexical, and ran into issues with both - bugs, difficulty doing things like having different alignment for mobile vs desktop. It was very brittle and it would be troublesome migrating data structures down the track. I've put 1.5 years into this (added my own k8s hosting on GCP too - also with its issues)!

The second command line builder took me a couple weeks to make a simple version of. I describe my pages, sections in JSON and render predefined erb templates. I scripted up deployment to Amazon S3, Cloudfront, and invalidate the cache after deployments.

It's crazy I spent so long on the Saas version and didn't get to a working website, and with the command line version now have a couple sites up!

It's a cool experience to make your own site builder, definitely learn something each time you do.

Here are the sites I made:

https://www.madebyhelena.com https://LouisSayers.com

(Helena is my partner, I remade her site which she had created on a different platform)

I wrote too (and still maintain) a SSG, it's a fun exercise: https://github.com/darccio/zas

I see a lot of people building their own static site generators. There's probably a lot of common elements to the process, right? We should abstract those commonalities into a static site generator generator, so that everyone who needs to write a static site generator doesn't need to reinvent the wheel.

Lots of "don't reinvent the wheel" comments here. But if you're a developer, crafting a SSG for your own needs is a 2-3 hours project. Learning an existing one is roughly the same. But hey... it's a good opportunity to learn by doing, and even later appreciate other SSGs.

My own SSG is Django+Distill.

Did an SSG last month.

I had used pelican before; but I wanted to get a better handle on using Markdown and Jinja libraries "from the other side" as well. I would have needed to adapt my file structure or write some code to let pelican scan my idiosyncratic hierarchy to generate the posts.

Turns out Markdown is easier to use on your own scripts, than it is to tweak its configuration in pelican; and Jinja is quite simple too. Getting to use the "debug" feature to dump everything available to a template is nice.

I haven't bothered with RSS or sitemap yet, but i did do a nice calendar view render of my archive indexes; which i don't think could've been easily wedged into pelican's notion of how sites work. https://snafuhall.com/news.html

I have experienced both sides. First, I've written my own generator in Python (about 300 lines) but the code was not exactly maintainable and adding features like tagging was hard. So, I looked around and picked up Hugo. While I don't like the template engine it was not too much work, to set it up and offered everything I wanted. But Hugo comes with braking changes all the times! Plus the Hugo developers don't know what semantic versioning is, so you have to figure out whether a new release works with your configuration or not.

Now I'm on the verge to write my own generator again (probably in Kotlin or in Rust), because I'm tired of Hugo's breaking changes and because I still don't like the ugly Go templates.

A fun experiment I’m sure but it’s not a very convincing argument for writing your own generator. In the same way the author claims frameworks will change, so will the tools that power their custom solution and using a framework will take a fraction of the time to get going.

  I know what you're thinking and you're right, it's way more work than using something
  that already exists. But it's also so much more fun. You can do anything with this,
  and you don't need to read documentation or try to understand other people's architectural
  decisions—just start writing code!

Great argument for never writing your own SSG.

Back in the day we didn't have SSG's. We just wrote the html/js/css by hand, and then used the existing browser and web server features to keep it DRY. No frameworks, no generators, no complexity. It wasn't fancy (or pretty) but it was simple and it worked.

I think the answer depends what kind of site you are targeting. For a clean and simple text blog it may actually be optimal to build something from scratch using building blocks you know well.

But for a larger site that might evolve and get more complex over time the DIY approach will likely hit the reinventing-the-wheel dilemma multiple times.

Its better to figure out which of the existing SSG's has a programming model that fits your brain and simply learn it well so that you can extend it in any which way you like.

As a bonus, instead of yet another half baked ssg, you can contribute something back in terms of plugins, themes or other code and feel good about yourself.

I agree.

I don't mean to say you should not share it. You constructed something good, you feel pride in your device, by all means share it with the world.

However static site generation is one of those simple fun rewarding types of program to make. The programing is straight forward, the results are linear with the input, that is, there is not a huge amount of boiler plate you have to wade through to see anything. Basic batch data transformation like this is the perfect environment to metaphorically "putter around in the workshop"

Nothing wrong with using someone else's, but really, you should write your own.

Considering that a vast majority of people who decide to learn a static site generator never end up really developing their static site much beyond a few articles talking about their static site generation process, I think there is definitely more value in just going all the way and writing your own static site generator from scratch. The code is the true purpose, not the final output. And the thing about a static site generator is, once it works – you’re done. You can put the project away and move on to other common things like building a tile map editor, etc.

I fully support the idea that writing your own SSG can be not only a great learning experience, but also a chance to make your SSG do exactly what you want it to (and nothing more).

I've written a ton of little SSGs over the years, and every iteration I've learned what kind of features I really need, and which I don't.

When I started working on the current version of my personal website (istigkeit.xyz), I also wrote a new SSG just for it. The program is called Hyphae[1], and it's written in Ruby using the Kramdown markdown gem, and pretty much nothing else outside the stdlib. It works perfectly for me, and that's all that matters (that being said, the code is up there, and licensed with the Unlicense, so anyone who finds it useful is free to use and abuse my clumsy code to whatever extent they want).

I'm a big proponent in the idea of writing personal software: that is, programs that are made by you, for you, and with no expectation that they'll be used by anyone else. I think too often developers these days get caught up in trying to make their project be "the next big thing" in whatever domain it serves, but honestly sometimes it's nice to just write something for yourself :)

[1]: https://gitlab.com/henrystanley/hyphae

I too had build my own static site generator. A buddy asked if he could use it to build some sites, so I invested in it being more polished. Put a REST API in front of the engine and file management, and then an AJAX SPA on top of the API. Over the years, it's been used by a bunch of web sites - large and small. The largest was Longwood Gardens - which had hundreds of pages.

This was about 20 years ago now. Once it a while I consider refactoring/resurrecting it. But I've not found the time.

when I made https://carefulwords.com, which is just a thesaurus that I wanted for myself*, I effectively had to make a static site generator, since it required a lot of preprocessing steps to get all the words linked to each other, word synonym lists, and word quotes assembled from various text files. And this article is right: you can just build it. I just put together some TS scripts over a couple weekends to smooth it all together (and then another day on top to make it fast). After that I can keep using and editing my weird bespoke sources to build my project.

If I had to use a static site gen to do the same thing, it probably would have taken a lot longer, or I might have had to do so much pre-processing or massaging of my data that I was effectively building a static site gen on top of someone else's static site gen. And why bother with that? Of course if the project had any more complexity, I would benefit from stronger templating, and putting a static site gen layer after my own static site gen is probably exactly what I'd do. Just stitch them together, instead of trying to get my first-steps into someone else's static site gen.

* I wanted one that has lots of synonyms, has some historic quotes to go with words, has autocomplete and unlike good old thesaurus.com it should focus the text box on load

The result being perfectly static means its perfectly fast. It also means there's a lot of crude overlap - every page has the same HTML copied and pasted a million times. But that's OK, it's small, so it's still faster.

Maybe don't write a static site generator. Maybe just make a normal website made of individual HTML and other files that doesn't require any "generation" at all. Static site generators are supposed to be for getting away from complexity but most of the time they just shift the complexity away from being attackable.

There's no requirement for websites to be generated either statically or dynamically. The best websites are just files in folders.

    <p>whatever stuff here...lorem ispum, etc...</p>
    <!--# include file="/menu.html" -->
    <p>etc etc</p>

I would ALMOST agree.

Five years ago I dove into using an ultra-light-weight framework called MetalsmithJS. It's super minimal, but does what you need. I'd spent 10 years using the Drupal monolith, and did not regret the move. Yet it's open-source community dried up, but mostly because the framework does what it claims and then stopped expanding!

Here's a blog post... https://doublejosh.com/post/186193119278/metalsmithjs-is-sti...

Then two years ago I needed a more robust SSR system based on React, so I went with GatsbyJS. It's insanely mature and intuitive, but as we all know that community and business is now drying up too. But the framework is still great.

Now everyone sings the praises of NextJS, which can be used for SSR but is intended for applications and active server endpoints. But more complexity doesn't mean better.

I'm keen to try other simple frameworks when the result is a static site. I may give https://www.11ty.dev a shot.

Just like a bunch of us here, I also wrote an SSG.

I setup a cronjob to fetch weather data and run the SSG to parse the XML and render a weather "website" on my VPS.

But for the blogs I've had/have, I just use a pre-existing one (zola). There are hundreds of SSGs out there, why bother building yet another one if one already exists for transforming your preferred base doc (markdown, asciidoc, morse code, etc)

> e.g. Quit dicking around with your SSG and write the damn blog post already. The hard part of writing something worth reading is not your tech stack.

Alternately, for many, there's more value to themself and everyone else if they grind on those technical skills rather than distract themselves with a hobby they seem inclined to put off.

If you really want to write, you'll write. If you really want to hack, you'll hack.

A lot of people think they should write, but actually just want to hack. And that's not a problem! The image of writing provides some orientation to the hacking, but it's the hacking itself that can be most fun and enriching for them.

Do the hacking, and if you never get around to the writing, don't sweat it. If you're honest with yourself: it was never really about that, was it?

> The hard part of writing something worth reading is not your tech stack.

This project isn't about blogging, you need to look at it from a side project pov.

I think this is a common misconception, that these people want to write a blog post but are failing or procrastinating when they don't have to. When in reality, these people are developers and makers who look at their personal website from tech community's "little corner on the internet" pov.

They feel frustrated with the solution and feel they can develop better-tailored one for themselves. Putting out blog posts isn't a priority or a concern for most of these developers. They're passionate about their tools. They make tons of side projects. They're not wasting time. They don't necessarily have a more important post to write about.

If you're looking at it from a blogger/writer's perspective, sure that's wasteful, but, again, that's not what this is about.

> It's a procrastination time hole

Yep. You also see this often in small companies/statups that would write their own ticket systems and internal administrative intranets before they even had a product.

Fun, learning something new, unlocking additional productivity in authoring posts from a customizable templating engine... I can easily convince myself of necessary reasons ;D

As long as you use a static site generator instead some bloated blogging platform with tons of scripts and a database.

If you write about tech and your site doesn’t load instantly why should anyone read your words since you obviously don’t care

Thanks. As someone who's prone to getting hopelessly sidetracked in projects, I needed to read this. I ended up forking and customizing pug into my own templating language!

My grandfather used to talk about most hobbies this way, until he got a little older and mellower in his later years.