Why You Should Write Your Own Static Site Generator | Hacker News Reader

Why You Should Write Your Own Static Site Generator

arne.me

187 pointsabahlo131 comments

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.

> I'm certainly guilty of writing a few myself.

So am I. My first one was written in C in 1995, and the resultant site run under NCSA Httpd. DIY-ing becomes tedious after several cycles, though.

On the other hand, my experience with generally available SSGs has been miserable. They keep breaking my site after a few upgrades. At this point, I am very close to just spinning up wordpress for a new site.

Well, that gives you more opportunities to have to update plug-ins and dodge vulnerabilities. Maybe a ton of people are a good fit for core WP these days, but I can't imagine the overhead of knowing what to update beyond the auto-updating core if there are a bunch of extensions.

I admin a local org's WP site, because someone has to, and thoroughly appreciate the SSG that I use personally.

Exactly. So writing your own generator doesn't differ from using a simple tool. At some point also this solution might not be robust enough.

Surely you can learn a lot in the process, but how much time does it need?

It was probably the author's fault to select NextJs for it. Maybe something simpler like gohugo might have been better: the tool is just a binary file, that doesn't require extra dependencies.

But if you write a static site generator, you can blog about it. And that can be the first and the last post of your blog.

If you don't write one, the chance is good, your blog would stay empty.

Why are you personally attacking me like this?

In all seriousness does everyone and their mom write a static site generator? I did because its fun and easy. Off the shelf ones can be cumbersome and not work quite how I want them to.

I've thought about it only because I hate having to figure out someone's frameworks and way of doing things.

I'm not a professional programmer and it feels like most of these are for people who already work with various frameworks professionally and know their way around these things. I am too old to spend time trying to figure out all the frameworks so I'd rather just whip up something with my half-assed skills and DIY.

I made one for a single page that I wanted to template nicely without introducing dynamic pages (wasteful since it's always the same file anyway) or JavaScript (wasteful since the layout is always the same anyway)

I'll probably do another one again soon, just so I don't have to rewrite my HTML / RSS by hand to publish another post.

Lua is a nice data language, so I just put the data and the code and the HTML fragments into one Lua file, no more than 200 lines. No worries about injection since it's all my data with no backend code at runtime.

> Off the shelf ones can be cumbersome and not work quite how I want them to.

This is why I wrote mine! You just put all your markdown in one folder, run it, then collect your HTML in another folder.

https://github.com/donuts-are-good/bearclaw

> Off the shelf ones can be cumbersome and not work quite how I want them to.

Yeah, that's exactly why I reinvent wheels!

I ended up forking an existing templating language and customizing it into a static site generator. I'm not sure what's more difficult: changing other people's code or doing it from scratch.

You forgot 3rd option maybe hardest - just using other people code and understanding it instead of misusing it, calling it crap and going to write ones own broken thing. ;)

I don't think I ever called anyone else's work "crap" though. The software I forked is the pug templating language. It's unmaintained, looks like the author has moved on. Most of my work involved deleting the features I didn't need so that it would be easier to understand and work with. It had a Javascript parser inside it.

But yeah, I get what you mean. It's definitely the hardest thing to do.

I guess he wrote „you“ in a generic sense.

Also, every 2 years post "I've neglected my blog for a long time, but that's about to change now!" ... and then another 2 year silence.

Guilty as charged, many times over. Sometimes, to the point where I could not even recall the old workflow post login.

Sounds like you are the visitor my blog had?

This is the perfect summary all the setups people have, with lots of "wow, I feel personally attacked" included: https://rakhim.org/honestly-undefined/19/

Nice. Your comics are rather amusing.

I agree. I also wrote two static site generators, two dynamic ones, and used a few prefabricated solutions.

Then I discovered that for my writing style, org-mode with embedded scripts and plotting code really just works. I don't have to think much and I can focus on just writing. That particular authoring/publishing tool never gets in the way of what I want to express.

So I ended up patching over parts of org-mode to make it my static site generator. Sometimes the best is somewhere in between the extremes.

Writing should certainly go first. But once you have passed the first iteration of your own self-built static site generator or website the "initial" content may already be there from the previous iteration.

I certainly learned to keep the featureset of such a program to a minimum in order to have a chance to "complete" and publish it.

Btw. the article lists five points that really come close to how such a generator may work. I think mine only leaves out the CSS compilation stuff and offloads the Markdown processing to pandoc...

Also guilty of writing a few SSGs and blogging about them. Proud to share that now I rsync my half baked writing directly to prod!! No build step!

I'd back you up there, and maybe go one step further: Blogs are the worst use case for a ssg and you should focus on writing first. It's the articles that make or break a blog, and you might actually want the comforts of a dynamic blog engine. Plus comments, trackbacks and pingbacks, so it is a real blog.

Where static site generators shine are websites that are not blogs. Especially when generated from a data source. Then you can tailor your ssg to the data source, update the data and run the generator to update the site.

I created md2blog[1] specifically for this reason: it prevents you from making design decisions, so you’re forced to focus on writing posts instead.

I’m well aware of the irony of building yet another SSG to help people avoid doing the same. But I’m addicted to building SSGs—this one was my fifth, and I’m considering making another one (insert facepalm here).

[1] https://jaredkrinke.github.io/md2blog/

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.

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

> 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.

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

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!

> [...] 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.

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

Because it's a hassle and you'll be left behind when you need a new dependency or there's a feature you like. By then, you have years of updates behind including depreciations, conflicts, etc. It might turn to a full-blown migration. All that is much easier if you update along.

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.

I built my own on top of org-mode: https://github.com/bastibe/org-static-blog

And also various others, for various reasons. The thing about static site generators is that they are fantastically easy.

> 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.

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

Shame...

Anyway, my first and only SSG was based on Atom for storage, PHP for backend and XSL for client side rendering.

We called this flat file CMS which was the style at the time and...

This is presently how my website works. I'm no webdev so I'm probably committing all sorts of heresies, though. I use m4 macros to build the header/footer structure with links and coloring and whatnot. Then the content pages are emacs Org files I publish to HTML and include with the m4 macros. You can do a surprisingly large amount with Org Export.

> 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.

If I ever were to start blogging, that's what I would do. Or at least that's how I would start out. I can't really imagine how a site for my own blog would need more than that. Learning HTML well enough to write a blog is not any more difficult than learning the ins and outs of another markup format, plus how to use the site generator and template system.

I do the same, but after a while I got fed up with the tedium of hand-managing the metadata and all the duplication that happens if you add OpenGraph, Twitter and Dublin Core.

So I wound up storing the basic metadata in a JSON file, then I assemble the header and footer of the page with PHP, which is then rendered out to a complete HTML page.

It's not quite a SSG, but just a little help automating the boring stuff.

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.

There are a few that take that approach, but people usually want one in their preferred programming language/runtime. Examples:

Metalsmith (Node/JS): https://metalsmith.io/

Haunt (Guile Scheme): https://dthompson.us/projects/haunt.html

I’m sure there are many more.

A while ago you were looking at small languages such as lua - there's also micropython. https://docs.micropython.org/en/latest/

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.

It's 2-3 hours for the first version. Then you want to add something to the website, and you find you don't have the feature for it, and need to spend another 2-3 hours. This repeats every time you're adding something and becomes a massive time sink. But if you don't mind, sure it's okay.

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 know people write SSGs because of frustration with their existing one, but did you consider writing a tool that "publishes" to Pelican? That's kind of what I do: I write all my posts in a single org file, and have Emacs process them and output rst files for Pelican's consumption.

I did consider that; but I had other nebulous project ideas that benefit from getting better hold of Jinja, especially. Those ideas have grown considerably now, I'm glad I did my SSG, its given me more confidence in those notions.

I have used pelican for my website for a decade now.

I also host my book-draft on my site. I initially tried to get Pelican to do it, or to write something that publishes to Pelican, but it just didn't work. I ended up writing a hundred lines of fairly simply python to do the same job.

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.

You don't have to update it either.

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.

This isn't really all that true and is highly dependent on the stack you want.

You can run Java from 1.1 on modern JREs. PHP from the early 2000s can still work. It all depends on what your stack looks like. If you're using the highly unstable "everything moves fast and constantly breaks" newer stuff, then sure. It's hard to see Python 3 breaking within the next 5-10 years, after how well the 2->3 changes were received.

I'd wager though even with newer languages, if you wrote something in Go, Rust, Kotlin, etc. today, it will still function in a decade.

I have a .net 2.0 app still running with installs that I haven't touched in over ten years.

  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 maintain a web site for a small club I'm in. I use an existing SSG (Zola). My goal is that people can get information about when the club meets, about our events, etc.

I do not care about how "fun" it is to maintain, I care if people can get the information they need. It should take as little effort as possible, because extra effort maintaining the site has to be taken from something more valuable I could do with my time.

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.

These are all good arguments why somebody can write their own (unlike e.g. rolling your own crypto), but aren't convincing me at all as to why I should.

I've used a static site generator myself to host a blog, and I've been pretty happy with it, yet I've never felt the need to write one myself even for a single second.

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.

That's a great start, but the problem comes when you want to have a site menu and breadcrumbs and then you want to redesign it. No problem for 5 pages, but if you have even dozens you'll start wanting to do something more automated.

Use nginx (or whatever) and use server side includes for templating footers/menus/etc. It's extremely simple with the lowest possible attack surface for it's expressive power/utility. SSI should have never faded from the web dev toolkit; especially since it's actually still there in every popular webserver. Just,

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

I use it extensively and it's great. You're still just working with .html files in folders.

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.

I built my own static site generator with Drupal 8 for a project. It was a good experience and made my company a lot of money.

We went with Gatsby for our overhaul and honestly, not looking back unless forced to. I realize it doesn't scale all that well but we're at ~10,000 pages and our build time is about 8 minutes without a lot of optimization. Given our refresh interval is 15 minutes, nothing to worry about from my perspective.

People keep chattering that NextJS might suit our needs better but GatsbyJS sure ain't broke.

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)

> There are hundreds of SSGs out there, why bother building yet another one if one already exists for

It's really not that rosy tbf. I went through something like: SvelteKit, 11ty, Astro, Zola, hugo, and possibly others in-between.

It's pretty easy to develop a preference where none of the mainstream SSGs fare well at. Some established large SSGs might do X but they have their own challenges too.

You start migrating by filtering based on some criteria, and find a match that does a great job initially, only to get bitten later, when you've migrated and settled and start seeing the cracks.

For example, Zola, and many others, doesn't support asciidoc. The handful that do have their own problems too. (I'm now with hugo which support asciidoc but I'm still determined to build my own ssg)

It's not fantasizing about the perfect tool, as much as developing a setup where you're comfortable and happy. Especially in the case of SSG, where you're more exposed to the internals and by extension any errors/problems.

The most commonly missing SSG feature for me is being able to transform relative links between Markdown files (which VS Code happily auto-completes for me) into relative links between the resulting HTML files.

Similarly hard to find is tagging posts based on file system metadata (e.g. everything in “posts/linux/“ should be tagged with “linux”).

I didn't realize this was so common. In my crazy days I wrote a SSG using only XSLT, so you wrote a big xml with the content and it would output a full site ready to upload.

It needed a specific XSLT processor as most couldn't generate individual files, but it was nice that it worked with off the shelf software, so technically I didn't write a single line of code.

(XSLT is madness, don't attempt)

I also did this, except the XML file itself was generated from a file system tree.

XSL did eventually add multiple outputs, but yeah: do not attempt :)

Absolutely agree, I did a fair bit of both and I really regret using the framework du jour.

I have a lot of websites (maybe more than 20) and they're a mix of old version of next.js, hand rolled websites and some solid.js websites.

The solid.js sites are fairly easy to update - but it's also very new (the oldest being 3 years) and I'm not sure it will stay that way forever. You just need one wrong decision from the fun guys at ECMA and frankly I've been burned already by commonjs vs esm.

The handcrafted sites from 10 years ago have some old and simple dependencies and they work fine. The next.js stuff is a horrible nightmare of different errors. Everytime I need to do a one-line change I get to do a nice debugging session. This is also a combination of the providers I'm using not having a fixed node version, but I've also found some dependencies breaking compat from one patch to another.

I guess the key takeaway is: use as little deps as possible.

I've written my own in (over the years and in order) PHP, Delphi, Ruby, Python, C#, Go, then C# again (after moving from Framework to Core) for serving my blog [1].

- It's fun

- It improves with each iteration due to experience gained

- It's great to have a sample project to create in any language you consider using as it's a small yet realistic way to discover how that language works and what the ecosystem provides

[1] https://kcartlidge.com

As an aside I also quite like yak-shaving - which is why for my latest C# iteration and just for the pleasure of it I've written my own Markdown parser and am working on my own templating engine (bit like Razor, ERB, or PHP).

I built one. I run a content website for a living so it was worth it. I wrote about why here: https://nicolasbouliane.com/projects/ursus

The short version: text files let you use powerful tools, not just the WYSIWYG editor supplied with your CMS. Navigating markdown files in Sublime Text is incredibly fast compared to clicking around in a PHP admin area. I can even write blog posts with Obsidian on my phone.

It also means a very simple, very fast server that runs forever without maintenance. You don't need much to serve static files.

Above all, it means source-controlled content and content branches. This is great for big changes that span multiple pages.

I recently had to nuke the Linux environment where I had my Jekyll environment finely tuned (Ran it on Debian WSL). Then I realised I had to reinstall Ruby, but the current Jekyll version (or the gems I use) uses a version that needs to lock OpenSSL at a certain version because of some breaking changes. Tried to lock the version in Debian and I was having a really hard time.

Then I realised I just could grab the latest Jekyll image from Docker hub and build my website with it. And just like that I was able to build my website without dealing with any ridiculous dependency.

So yes, you should write your own static site generator because it might be a tad easier than trying to install from scratch the dependencies of whatever generator you have chosen.

If you used Go (or something equivalent) couldn’t you bundle it into a binary and then it can be more portable?

It's good to have a binary that you can run, but you'd still have to deal with Go dependencies at build-time, and Go dependencies sometimes can go sideways as well (probably not as bad as Ruby, though)

Yes, build time will still be an issue. Hopefully if you get to a point where you’re “happy” with the binary you can avoid build issues for a while

I had the same idea as you and rewrote my blog CMS. Initially it was very similar to yours, with Maud [1].

Then I started a little library for replacing Maud, for a better developer experience [2] (still looking for a better name).

The important thing for me is having fun in the process, my personal website is a sandbox for playing and experimenting :)

[1] https://anto.pt/articles/rust-server-components

[2] https://github.com/Pitasi/rscx

Another option that I’ve found worthwhile is to write a Jekyll Plugin, so you get a stable base for your SSG, and you can experiment with adding weird functionality on top.

For my news website, I needed to scrape some news from a third party API, and I just moved it to a Jekyll plugin so it embeds neatly into the website. Works quite well: https://github.com/captn3m0/news

Another place where it made sense to use SQLite as a data source, I wrote a Jekyll SQLite plugin.

Nah. I'll stick with Pelican. It does what I want in a pretty straightforward way, and there are tons of themes and plugins available for it that I don't have to write.

I've been very impressed with Eleventy:

https://www.11ty.dev/

I find my lingering desire to roll out an SSG slowly fading.

Hadn't heard of Eleventy, I thought Zola was where you went for speed, which they don't even bother comparing too.

Found this post comparing them & more, Eleventy (man that's annoying to type on mobile with autocorrect though!) for speed it says. https://mtm.dev/static

Love the build times, thats for sure.

I'm really attracted to the Eleventy approach on the whole - there's no bloat, they don't inject any of their own js, I can move fast and only add complexity where I actually need it.

And they emphasize on their stability. https://www.11ty.dev/blog/stability/

I wrote one in elisp for publishing my blog directly from org-mode files in Emacs (because of course). It is super minimalist and works great for my specific use case.

I ended up writing my own because nothing did what I wanted (1 post per folder with all media inside the same folder, Wiki linking, partial rebuilds and various layout features). Never looked back, and today I just commit to my source repo and it goes and rebuilds and uploads only the pages that have changed (out of 9000 or so).

I did a very minimal version of this myself recently, and it was very fun! I don't even have Markdown - I just write HTML and have a couple of helper Python scripts to update headers, generate boilerplate for images, etc. It's nonscalable and not really for anyone else, but fun, easy to understand, and there is not much to go wrong.

I use a hybrid approach. Next.js is the base for my site but I use next-sitemap and a hand rolled content compiler (md -> html -> jsx) for feeds, meta tags, and generating every page I dont manually specify as a .tsx file.

I like having the flexibility to do either. Complete control in .tsx or just writing in .md. I would like to add .mdx eventually too

There is also a Static Site Generator written in Python. https://github.com/ahui2016/pyboke. I used this to generate my blog: https://yinan.me

As much as highly visible usages of GPT make me eye roll, I appreciate the up front summaries. It’s particularly well suited to technical blogs.

This is so cool. I did the same last week with pure php without any dependencies besides icon, gd and rsync for deployment. Feels like I had sitting inside a LAMP prison for the last two decades. Now just some json files are my database. No fancy bullshit. Just handmade code and some templating. I feel freed like you.

I feel there's something to be said about a static site with a simple PHP-based search function thrown in there. Perhaps it could have even the full site content pre-generated as a data structure in PHP, for keeping in memory. Could be just word->pageId mappings, if you want to keep it simple.

I wrote mine a couple years back and have been using it for a few blogs and anything I want to make a landing page for. Even built a mini game engine for it that loads up zip file games. Also added an editor and a backend for dynamic blogging and live reload.

These never come explaining Why html is to hard. Basics and ftp can be explained to a 12 year old in 10-20 minutes? I'd even argue (based on decades) that everything learned beyond the first 30 minutes is probably something you should not be using.

No one is saying HTML is hard. It is however, tedious to copy and paste your content into a blank template, update the meta tags, etc. Then update navbars and lists, etc. Now imagine a redesign, or a bug in that blank template thats now in all your pages...

The SSR isn't to avoid HTML, it's for template purposes.

For Swift there’s https://github.com/JohnSundell/Publish which is a framework to create a static site generator. It’s really good.

I mean, really, you should write your own static site generator framework.

Such a strange abstraction layer.

Thr author could have skipped a step and formatted using tags instead of markdown and published the html directly, with zero need for any generator. Using scp and html, like it was 1998.

I made a website that does all the markdown to html conversion right on the client and it still has great SEO. Apparently google and stuff will just index the markdown itself.

No compilation step needed.

Yara very interesting! I'm thinking about doing it but was worried about SEO. Doea it load, parse and draw the content fast?

Performance = 73

Best Practices = 95

SEO = 90

and that's using the marked.js library

I once wrote a static site generator in m4!! This was about 2002, and I discovered m4 while picking apart GNU autoconf. It was anachronistic (to say the least) even then.

I want to write my own SSG and probably will soon. My current site is built using Gatsby and oh boy it’s a lot more complicated than it really should be.

I wrote one and it's the only software I still maintain and am proud of. I'm kind of inventing a new React like thing in it. It's way cool.

I did write my own static site generator. Used gulp and used nunjucks and streamed a json file for content into the gulp build system...was 61 lines.

It's something worth doing at least once, but it's not likely going to cure cancer.

a spreadsheet, word template, mail merge, then save-as html and you're there :)

httrack converts websites to static I've had good success with it.

It downloads the dynamic sites and converts to static pages.

https://www.httrack.com/

Hmm. If I were to write my own I'd probably make a CMS rather than a SSG.

Just script it using any of your favorite tools, freemarker, jerkyl, etc..

Disagree. Just write raw HTML. It’s much much easier and gives you trivial control.

It’s much easier to write raw HTML and HTML-to-Markdown than the other way.

This is why the static site generator I wrote support embedding raw html :p

Not-invented-here-syndrome

I've never understood the point of these things. Just use a solid CMS and cache to s3 or Varnish. What's the big deal?

The deal is that a lot of static site generators are very complicated (perhaps needlessly so), despite the fact that static sites are technically very simple. Perhaps some people really leverage the power of Next.js, but when I tried it, I felt that it was super heavyweight when I just needed to template html files.

Of course, that doesn't mean I need to write my own. I just used a simpler SSG. In my case Jekyll.

NextJS is far more than an SSG; it's a general-purpose Java/Typescript app development framework for frontends and backends.

Being able to deploy a bunch of HTML files to static hosting services, no runtime like PHP etc. required.

If you use a CMS, it has to run somewhere. If you don’t want it on a server, you probably don’t have the same config on your dev machine. Most CMS require you to configure root domain paths etc. and they are different on your local machine. It’s all a lot more complicated than using an SSG to transpile a bunch of markdown files to HTML on a dev machine and upload them.

I prefer using markdown files in a repo and generating my website using a SSG, because I find managing plain text files and a simple CI/CD pipeline to deploy easier to manage. The tooling for writing is my editor of choice, deploy is a git push and I don’t have to run a server or long running process. I can also easily migrate to any type of hosting more easily. I can see someone who is more used to Wordpress for example finding your workflow easier. It really mostly comes down to personal preference and what tools you are used to.

How do you feel about this attempt at creating a better WordPress that we have been working on?

It uses Git and Markdown for easy deployments to your serverless CI/CD pipeline just as you described.

I'd love your feedback :)

https://github.com/elegantframework/elegant-cli

I wrote my own one also. It's ~100 lines of Go, generates the raw html that I commit to Git and which CloudFlare Pages automatically then deploys from a sub-folder for me.

I don't need to set up S3, Varnish, a server, a database, making sure my server + cms is up to date. It costs me $0, it's on a cdn and it's lightning fast + no headache. What's not to like?

Hosting a static site is simple and can even be done for free.

Even though you can make a CMS fast, with a static site you can forget about performance altogether.

Finally, it meshes very nicely with editing files in eg markdown locally, which for some people (like me who live in Neovim) is a much nicer experience than editing things in a webpage.

Cheap/free static hosting is plentiful, static sites don’t have packages I need to keep up to date to avoid vulnerabilities, and writing posts/pages in a format like Markdown makes them dead simple to migrate between systems. Additionally, using a service like Netlify or GitHub Pages affords flexibility — all I need is a git client, a text editor, and an internet connection that can manage to transmit a couple of kilobytes. Don’t even need a browser.

Aside from that, a CMS is overkill for something like a simple blog. I might consider one for a more complex site but for a blog there’s no need.

No maintenance.

When I had a dynamic blog (DB backend, etc), I got hacked because I wasn't updating the SW often. Not having to worry about things like that is a significant quality of life difference. I want to run my life, not have my tools run them.

But frankly, let's invert the question. What exactly is the benefit of using a CMS vs an SSG like Pelican? After having used the latter for over a decade, it's dead simple. Open a file. Write your content. Run make. And publish. It's trivial to back up. I don't have to know what a cache is. I don't have to keep updating SW. What is the actual benefit of a CMS for a single user like me?

Reply on news.ycombinator.com