Hacker News Reader

Comment by 411111111111111 | Hacker News Reader

To be fair, static site generators are a thing and are very much underused in cooperations.

He could have the same scores/performance and still get the full advantages you mentioned.

But yes, handcrafting html is pointless at some point, especially if you have to update the contents every so often

A static site generator requires a toolchain, being platform-aware, updating dependencies, etc. Sometimes I think of these things as labor for a new employee (if you need to onboard a new maintainer) on a new system (if you need to switch hosts or upgrade the disk/OS).

It's probably about 2-4 hours for an experienced developer to figure out how to setup and maintain a static site generator assuming no unexpected problems, then get familiar with the syntax and structure, so hopefully the labor savings from using a static site generator is worth that.

A static site generator requires the cat command.

I don't see how you can call yourself "lazyjeff" when you've just written this, tbh.

"I looked at static site generators like Jekyll, Hugo, 11ty, but all of these require tooling installed, have a build step and will ultimately need some updates or be abandoned by their maintainer." - from the article

Yes and to that point you could use something like Hugo, generate a static HTML site. Then with that static site in HTML/CSS you are no worse off the solution the author proposes even if that generator became completely abandoned and unusable the next day. But in the meantime your work would be a LOT easier if you are doing anything at all with headers/menus/accessibility

> To be fair, static site generators are a thing

There goes your super-lean stack and we're back to square-one.

Not necessarily, because I didn't specify the tool. You can even use pure bash to generate it if you want.

If you know what you want you could write a trivial script which just pushes a Markdown file through pandoc(unless you just write html), concatenates it with the files for the header and footer (& maybe an inlined stylesheet) and appends a link to the index file. The result will be the same but applying changes on all pages is a matter of seconds.

Nothing against a lightweight stack, but simplicity doesn't necessarily have to exclude functionality.

This was essentially my first blog.

He mentions that SSGs require tooling and dependencies.

And if all you need are dynamic headers and footers, just wrap those in 'php include' tags and rename the files to .php. It's still HTML and CSS that's getting rendered.

I’m not a web guy—- this should be safe from php vulnerabilities I would think, because there is no db and it’s just taking advantage of very limited/basic features of php right?

Php vulnerabilities are introduced by the developer.

The number of vulnerabilities is vastly reduced due to the static nature of the site. You aren't buying anything on it, or inputting other kinds of data that needs to be written to a database. It may as well be a read-only site.

I've used both server side rendering and server side includes. A static site generator beats both. Just have a listener that will re-generate the site live when you write new content, then just ssh/ftp the generated content to the server when you are done, or if you are fancy you can use version control and push to a repo with a CI toolchain that will regenerate and ssh/ftp it for you.

Reply on news.ycombinator.com