Maybe you just haven't found the right static site generator for your needs?

Jekyll is the most well known in Ruby space, but it's tailored to a specific niche - authoring a blog with Markdown or another lightweight markup language. You can certainly massage it into doing other things, but it's not that ergonomic as a general purpose static site generator.

If you want something that's easy to copy/paste into rails, a rack based static site generator like middleman is great because you can start writing with erb/haml and ActiveSupport from the very beginning.

If you're looking for the simplicity of handwriting HTML and CSS but you want some niceties like includes, partial templates, link helpers, nanoc is a good static site generator that's progressive. Start with plain HTML/CSS, only add additional features as you need them.

> Even as a programmer, I've fallen into the static site generator trap a few times.

> It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app.

Hard to discuss without examples. I started using Pelican over a decade ago, and am still happy with it. Every once in a while I write code to customize the behavior, but it's once every few years. It's simple and just works.

There are things I miss from dynamic sites, but I don't see how a simple folder of HTML files is in any way superior to Pelican...

I've been posting to my personal website for 20+ years and it's been something like: basic HTML -> Drupal (whew) -> Wordpress -> basic HTML (via Jekyll).

The fundamental rule I've set myself against feature-bloating in my website is defining what I want it to be: an archive of things I've done. As an archive, I want it to be very durable in time. Thus, static file that are dead-easy to copy around, mirror and make it work in any hosting platform.

It did take me a while to nail having a bilingual site, though :) but at least it's a price I paid once.

For blogging I use Hugo because it is just easier to focus on content, not on style. That is why I don't like writing pure html files. Changing style can also be a problem, if something is hardcoded into html file.

For more advanced tasks I write in django, because it so easy for me to add features.

> Nowadays, if I want a static site I just start with a folder of html files.

Same here. I've considered adding a .md —> .html step for content, but just haven't found it necessary — yet.

> The other cool thing...

I like being able to—easily—view my site via a local sever. The best case would be one that I can view via file:// too, but I couldn't quite crack the organisation and ended up with a 'make local' step that generates a separate copy for file-based viewing.

I run a blog for an organization. We do one post per business day on average, with typically around 3 posters. I set it up years ago with Django/Wagtail/Puput and it has happily chugged along ever since. I can’t imagine how annoying it would be to manage if people were creating their own new files for every post and writing their own HTML…

But you've had to maintain that Python/Django stack, as well as a server.. Right?! I've done hundreds of Django release upgrades. They're not automatic or time-free.

Most SSGs, especially those geared to blogging accept nicer markup systems like Markdown. Keeping track of things, even in a multi-user system isn't hard.

Getting non-technical people used to a git workflow is the hardest part.

Now I'm wondering what kind of features you end up adding to your website that need server-side code. Comment systems?

How about a contact form?

Here you go:

<form action="mailto:someone@example.com" enctype="text/plain">

In an ideal world yes. But from past experience many users have the association for mailto links misconfigured.

It's a terrible user experience.

Yes, it depends on the target audience. For a personal website which the article was about, it would probably be fine for most hacker news users. If someone can’t manage to send me a mail, they probably wouldn’t see my website anyways. If you do your grandparents personal website, a proper form with a backend is better though.

How are you handling commonality between pages with plain html pages? As long as you don’t use iframes, you have to manually sync everything that’s shared or almost the same on alle pages (header, footer, navigation). That’s pretty annoying.

> How are you handling commonality between pages with plain html pages?

I have a simple web component that lets me do `<include-file remote-src='...'>`.

That's basically 90% of what a more complex solution will give you.

<?php include("header.html');?> You only need to allow PHP to run in .html files (if you insist your files being named .html(

That’s what you would call

> Nowadays, if I want a static site I just start with a folder of html files.

? With that argument, we can also calculate 10 million digits of pi in HTMl by renaming our C files to .html. If someone tells me they’re using a collection of html files, I’m assuming they mean static html pages without server side scripting.

Pretty sure parent didn't actually mean plain html files for everything but if they did then perhaps they're using server side includes.

Yeah nah, for me it's exactly that: plain html/js/css files. For simple things, I copy/paste.. not a big deal.

If it's getting more complicated, I'll abort and upgrade to rails to use layouts etc.

The middle ground of static site generators are a trap in my personal opinion.

If I need to add a feature, I've found it's easier for me to implement it directly rather than try mess around configuring a static site generator with plugins etc.

Amusing how underneath this comment, there are several comments saying "ah, you just haven't found the right SSG, this one is good". Well-intentioned, but completely missing the point.