Sure, it's super easy when your page doesn't have even a header and/or a footer. Try having a top-menu in your design, or some banners/ads, and then you need to change ALL the pages to change a single url. This is how we used to do things long time ago, and it sucked BIG TIME, and that's why people invented server-side includes and cgi and mod_php and all of that... it saves time, and your time costs much more than hardware...
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.
"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
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.
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?
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.
> So... if I don’t use any templating system, how do I update my header, footer or nav? Well, simply by using the ”Replace in files” feature of any good text editor. They don’t need frequent updates anyway. The benefits of using a templating system is not worth the cost of introducing the tooling it requires.
>The benefits of using a templating system is not worth the cost of introducing the tooling it requires.
Other people use static site generation, you use search and replace in your editor - not much of difference. Your approach is slower in long term, but with your on average 1 article per year it will take some time until you reach the threshold.
Eh, I don't think a person can ever write enough articles and rewrite their layout enough times that search+replace overhead ends up bigger than the upfront time it takes to read jekyll/hugo/whatever docs (plus debugging idiosyncrasies, etc). And even if search and replace was slower overall, you might be looking at a difference of minutes over a period of decades (i.e. it wouldn't actually matter in any practical sense).
Far too often I see people spend days to save 2 seconds (and then proceed to not realize the savings over a long enough timespan)
In reality the time saved isn't the only significant factor
though, humans aren't machines after all. I'll gladly "waste" a
bit more time if that time makes the process more enjoyable in
the end.
You forgot to mention the main benefits! Your website does not fingerprint my device, nor present me with a dark pattern infested "do you want us to send your data to 50 ad networks" popup.
"Tooling" can mean many different things, it can be an over-engineered flow including a dozen of different tools, or it can be a few custom made scripts to glue together html for you... but anyway, it's one time setup, you invest 2 hours of your life once and if done right it can happily run your site for decades, plus if you did it before it's no brainer usually... hell, I even have some old wordpress sites that I haven't touched in 10+ years and they autoupdate and work just fine, even make a few bucks here and there (but it certainly helps a lot if one knows what they're doing when making the sites).
Back in the old days of web development in 1999 there was a great app called Adobe Pagemill for making changes across thousands of HTML pages. It was great.
These days you can do the same thing with about 5 lines of Python.
> it saves time, and your time costs much more than hardware...
And the user's time doesn't?
If you can shave off a bit of loading/processing time for every
request you will have improved the experience for countless
people. Sure, using just HTML+CSS is a bit extreme, but for many
sites the removal of some social media embeddings/trackers and
switch to static site generation could improve it by an order of
magnitude.
> it's super easy when your page doesn't have even a header and/or a footer.
It's not that hard even with.
My stack consists of HTML/CSS, and a small program to stitch headers and footers onto documents generated with markdown.
If anyone would like to see it, it should be in the Sourcehut page linked in my profile. The program is a hacky (but functional) piece of garbage however.
I did this. Had a header template, a footer template and a bunch of pages. My build script was basically ‘for page in pages cat header page footer > ouput’. Worked fine for its purpose (which was limited in scope).
That's just about what mine does as well, except pages will inherit headers above them in the directory structure, so I could make the top bar pretty without JS.
This is the exact thing I experienced and have been dealing with the past couple days. I wanted to create a small collection of pages as my website, intending to keep everything as small and simple as possible since it was (mostly) just to display some basic info and "posts". Well as soon as I wanted that menu for pages it was a whole new can of worms.
Sure, I could just copy/paste/replace content as it changes. But I don't want to have to be doing that any time I decide I want to change or add something. And I'm known to be a source of human error.
I ended up going Node+Express+EJS for the includes and certain more dynamic content on pages. It works well enough, page sizes are still small. Also considered some static site generators but at the time they seemed like overkill for what I wanted. Maybe there's a tool out there that will compile to plain old HTML files that I'm unaware of, I don't keep up much on front-end things.
to cover slightly more use cases, you could go for <?php include "header.php"; ?> like it's 2002, and then have that file just be plain html also. Of course if you're gonna pitch a solution that's impractical in most cases, you might as well go for the most extreme variant of that solution and not bother with that
