Comment by leonheld

For me its mainly:

  - the ability to update every page on my site at-once in a uniform fashion (want to change the page layout or add a link in the footer, either you're manually editing a hundred HTML files or a couple lines in a single template file)

  - Syntax highlighting. My blog has code blocks so I would have to manually invoke a syntax highlighter for each code block (and every time I update the code I'd have to do it again).

  - auto-invoking graphviz and gnuplot. Similar to the code blocks, I write graphviz dot and graphviz blocks as code in my blog posts and have my static site generator render them to images. If I was manually writing the HTML then I'd either end up committing the built binaries (rendered images) to git (which, of course, is bad practice but ultimately inconsequential when talking about small SVGs for the few charts/graphs on my blog) or I'd have to have a "build" step where a script invokes graphviz/gnuplot to output the images which is the first step on the road to a static site generator.

  - Avoiding name collisions with internal anchor links (the kind with the `#` symbol that scrolls the page). I use these for footnotes and code block references. I could manually assign names for these for each blog post, but when combining multiple blog posts into a single list-view for the home page, there is the risk that I might reuse the same `#fn1` anchor across multiple blog posts. Using a static site generator, I don't need to concern myself with naming them at all and I have my static site generator assign unique names so there are no conflicts.

Because then you have 200 blog posts and suddenly you realize "oh I wanna add an author section to all my blog posts". That is 200 files to edit. Could you write a script to do the edit? Sure, but then you pretty much build a static site generator.

Writing raw HTML is just not fun for some people.

Obsidian is a nice middle ground between WYSIWYG and plain text - it doesn't send markup characters into the ether but at the same time does show you something close to the final text in real time.

Closest thing we've had to WordPerfect's Reveal Codes in decades.

I thought this too, but then it hit me that it will need pagination as the number of blog posts grow. Also updating links, footers, menus, headers etc also quickly becomes a nightmare.

Id like to see you writing a semantically correct, accessible, responsive <figure> block containing an image of a chart displaying some data.

It takes me nine characters plus URL and alt text in markdown using Hugo. I would be surprised if you get it right on the third try without consulting MDN, spending time to research, do image conversions, and fiddle with the <picture> tag and its srcset attribute.

Changing common parts like the navigation becomes a bit of a chore without a ssg as soon as your site has more than a handful of pages.

That's a very technical perspective. If you're a note taker, you ALREADY write in a format that is comfortable for you. And like the vast majority of people who enjoy putting proverbial pen to paper, you aren't thinking about bloody html tags.

The goal of generators is to reduce the friction of taking your notes/articles/etc. and wrapping them in thematically consistent HTML/CSS for your site. Once you've got it tuned/setup for your blog, they're pretty easy to use.

Obviously in your use-case where you find static site generators more complicated, then you can stick with raw html.

When I want to write longer content, the last thing I want to think about in that process is html tags. Doesn't matter how simple - if it distracts from content, it has no place at that stage of the process. I'm also very likely to include code snippets in any post I write and I extremely don't want to write the code colouring by hand every time.

Because writing in markdown is a nicer experience. You could convert markdown to html using Pandoc, but another nice thing that these blog generators do is templating and indexing. Neither of which is necessary, but still, they're nice, especially if it happens automatically when you push to github.

How do you plan to manage 1,000+ posts with HTML and make changes that are similar across all pages, say, the location of your static assets (images) or something common like footer, nav, etc?

The separation of template and content is the reason. You don't want to have to run a find and replace to add a new link to your sidebar or whatever.

The input is markdown, the output is HTML. How do you bridge that gap without generating HTML?

Because I don't want to publish the millions of draft posts I'm procrastinating on right now