Follow

As some of you are aware, I contemplated switching to a static site yesterday. That thought has been slung from the window at a rapid rate. Here's my completely unqualified rant:

ttmd.grayw.co.uk/a-static-u-tu

Thank you to everyone who took the time to send me their thoughts and suggestions.

@gray I don't think you're wrong here. That certainly seems like far too many moving parts for what is supposed to be a simple technology.

I just use git repos (easy enough to sync with push/pull) and my own static site generator I wrote as a shell script. It uses rsync to upload the files to the webserver (and sometimes there's some manual copying which I don't mind). I also don't use my phone much so I don't have to worry about that front.

@gray yes! So much yes! The simplicity of a full fat CMS is so much better than the complex nature of SSGs (in my opinion). I too think they’re massively over-engineered and I don’t have time for that, quite frankly.

Yeah, my WP instance might get popped, but that’s what backups are for...

@kev Precisely, and backups are one of those things you have to learn the hard way in life 🙂.

I feel a lot of the tech/solutions are incredibly over the top these days. All trying to re-invent the wheel.

@gray @kev In general I'm with you, I see the major benefits of static sites in two factors:

1. When you don't pay attention, you don't pay attention there is basically no risk of someone turning your page into a spam machine just because there was a 0-day discovered in some plugin during your 6 month of more important things

2. Validation of the entire page seems simpler (to me).

Obviously there are other viable solutions for those problems.

@sheogorath @gray I think what’s important here though, which often gets overlooked by many SSG enthusiasts, is practicality.

Wordpress is trivial to configure to update automatically, and I’m not sure Ghost even has a plugin ecosystem? Anyway, like I said in my previous comment, is something was to get popped, restoration is also trivial. Plus, it’s a personal website, so no big deal anyway.

@sheogorath

They were exactly the sort of benefits I was looking for, along-side attempting to save money. I wanted to cut down the attack surface as much as possible and just make it all simpler.

As @kev says, the practical side of it just didn't seem to play out that way.

I think my mistake in the whole thought process was wanting to re-create what I had and I wasn't willing to compromise there and take a step backwards. In turn, introducing complexity.

@gray @kev I use rsync. It's simple, I understand it and it just works. I know this because it's saved my skin more than once.

@gray @kev Yes. My first lesson in backups was losing digital photos. The harder lesson was when the wife discovered this fact ('Christ - you had just one job...')

Even now, when upgrading, I touch a dummy file, ensure it gets backed up before embarking on any major changes. You'd be amazed how many times my FreeNAS has dropped offline and regular backups haven't been working. Not often but enough.

@andyc 🤣 I think photos is probably most peoples first lesson. Your harder lesson resonates well with me.

@kev

@gray @kev I have used SyncThing more than once which is great for real-time, seamless multi-way sync with no shitty proprietary size restrictions.

However there's just so many moving parts. And each moving part can fail. And it's time consuming and hard to diagnose and troubleshoot. Similar to your SSG experience.

'I am a bear of very little brain'.

But also the Un*x philosophy is to 'Do one thing and do it well (preferably from the command line)'.

@gray @kev /me wonders why I just don't ping my FreeNAS and send an alert if it's down.

Nah - too much work.

@gray after all this years with static vs dynamic content wars I just got into a conclusion: MovableType folks were *right* and we were all wrong: Be a dynamic CMS able to generate static content for consuming, whenever you change something via their simple web UI all the relevant static content would be re-generated.

@esparta I think the key word in there is "simple" rather than who is right and who is wrong.

I find it incredibly simple to manage full blown VM's and everything that comes with it because of my background.

Software developers find git commit > push workflow simpler because it's already something they are doing every day. Whereas for others we have to go out of our way to use those tools.

Thank you for taking the time to read my post :).

@gray
I think fundementally that is where the divide comes in. They are based on two different knowledge bases with processes and assumptiond aligned to their coresponding methodology. Very astute train of thought and great take on attempting to make a switch.
@esparta

@gray I've had the opposite experience, and have found static sites much easier to set up and maintain.

I can create a Git repo and have it update the website on each commit, hosting it for free on GitLab or GitHub pages. I'm a programmer though, I'm fine with Git and writing blogs in plain text.

The alternative is having to set up php/whatever, potentially in docker, and faff around configuring it all. On a server I need to pay for

@gray Well, I already pay for multiple servers. The Git aspect of it - having it version controlled and reproducable - is super nice

@rubenwardy This was another one of the reasons for the experiment. I love the git angle and the idea of version control. It's saved my arse on many occasion when it has come to configs of some kind.

I find it truly fascinating in how we all find different things simple because of our backgrounds in tech and how we got in to it and managing a full blown server to me is something I can do on autopilot.

Now, possibly adding the complexity of docker in to the mix is a whole different ball game.

@gray perhaps I make it difficult for myself, I don't like running services directly on my server as it's been a pain in the past (in terms of being able to move servers, and not having the service spread everywhere). I instead use docker. I also use nginx and not Apache, which makes running the inevitable PHP CMS more difficult

@gray the concept works well at scale but is bad at the small scale of a personal blog. I completely agree with your blog post here. Modularity is unnecessary and too much overhead for a one-man team maintaining one site and probably only updating one page at a time.

@greypilgrim That's a very good point that I hadn't considered. A lot of this tooling is coming from people who are managing sites at a vast scale. Something I am never going to need to do for my blog :).

Thanks for reading.

@gray Sounds to me like you're right in terms of selecting what is simplest for you. I'm a software engineer, so the static site generator workflow of having source 'code' files in git fits neatly into my preferred way of working, so it's simpler for me.

I also never try to write anything on my phone anyway, because I hate touchscreen keyboards 😅 .

@jworthe Indeed. I think that's a key angle - considering what is simple for that person. I'm a simple man...

Managing VM's at scale and everything that comes with it is simple to me coming from a corporate side of things.

As you said, git is already in your regular workflow. For me, it's not something I use on a regular basis.

For the phone, I mostly use it to tap in short brain farts as opposed to full blown writing. That would be a bloody nightmare 😀.

Thank you for reading!

@gray Good read :) I went over to Hugo, but in my case chose to cut out the Git stuff and complexity. Instead I'm syncing the whole content folder to my various workstations and phone with Resilio Sync. For my needs, it keeps a 30 day history of file changes, if I make a mistake, and I set up a dirty cron job that just runs the hugo build task on the VPS twice a day. So I update a content post on my phone, it syncs up, and a few hours later posts live.

@gray Before that, I had researched the same rabbit hole of Git repos, CI/CD Deployment, Forestry and all that complexity, but it was way more than what I needed or wanted. So now it uses the process I described, on my VPS with my existing Nginx reverse proxy sitting infront of it.

@techzerker That's a pretty cool method of working it.

Interesting that you're still publishing it up behind Nginx though. At that point I'd find it quicker to go my existing route.

I love how we all get to the same results from very different paths.

Thank you so much for taking the time to read my post!

@gray Thanks! Aye, in this case its just behind nginx because the same VPS runs my Miniflux RSS, Subsonic Server, and a few other products that nginx helps with subdomain routing, so it was easiest to keep it consistent even though its not necessary for the static site.

@gray All very valid points! I have often wanted to move away to something like Ghost as well - but the ~ $60/year makes it a non-starter for me.

@celia A full blown CMS certainly has negatives too. It can't all be sunsine and rainbows and while that $60 is a cost, I also feel it gives me the freedom to experiment with other things too with that same server.

How do you host your site right now? It's gorgeous by the way, I love it. It is exactly the same kind of beautiful simplicity I was attempting to achieve.

@gray I agree with the several things on a single VPS benefit. However, I also have benefits I am not willing to give up on a hosted static site. For example, right now I am able to use branch specific builds to have a publicly available "staging" site, if you will. Another benefit - zero maintenance, it never goes down. This whole setup is complicated, but it's free, so I don't want to complain.

Thank you very much! 🙂 It's an Eleventy static site hosted on Vercel

@gray The problem with complexity is not static versus dynamic. You are right that there were way too many moving parts.

The actual problem, however, is that everybody is used to answer a question in the form "How do I do X?" with an answer like "Use service Y". More services, more complexity.

Better try to accomplish X with the tools you already have. The world really becomes much simpler then.

@ewintr Agreed.

I think my major issue was rather than coming at it from "I want words on a page", I attempted to recreate the environment and experience I had.

This, of course, resulted in more things in the mix increasing the complexity of the project.

Thank you for taking the time to read the post :).

@gray I think you may be over thinking it, lured by all the technology.

Static sites can and clearly should be simple. I use Hugo (one cmd) and publish to AWS S3 (one cmd).

@gray leaving aside the well trodden different strokes for different folks conversation.

I would have warned you off this path for the writing from a phone requirement alone. 100%. Not seen a user friendly suitable solution.

@basil Thankfully it's not something I do much but I do plop a few ideas in on occasion. It was a truly useful to have.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.