Hacker News new | ask | show | jobs
by icyfox 966 days ago
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.

8 comments

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

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.

> 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.
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.
Sounds like you are the visitor my blog had?
> 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.

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/

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.

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.

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

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.

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!