My website is one binary

Definitely agree with all the above. However, personal websites are neat because the only requirements are your own, so you don't need to justify it.

I love seeing solar powered websites, retro computers hosting modern sites, etc. Having a single binary is a neat idea too, even if it's a bit pointless.

It almost reminds me of the woman that came up with binaries that could run on different OS's unchanged. Definitely neat stuff!

There's a difference between trusting Go without reading its source (no dependencies other than the previous version of Go and maybe a C compiler if you want to bootstrap it from version 1.4, run in production at big tech companies, actively maintained by Google) and trusting Hugo (1200 deps, huge plugin ecosystem with less battle-tested packages, unaudited templates that could inject anything they want into your site unless you read each release carefully).

Golang is "only" 2 million lines of code, and it's quite easy to go look at the implementation of something, as the docs link directly to the code. It wouldn't be impossible to read through it, particularly if you skipped architectures other than x86 and parts of the standard library you didn't use.

I'm a big fan of single-binary websites like this one which rely on as little dependencies as possible (Small, well-written, auditable libraries).

What I've found in the go ecosystem as of the past few years is just this enormous graveyard of projects that didn't really seem to get the zeitgeist of keeping as much as close to the standard lib as possible, and included all the batteries. Now you open those old projects written in such frameworks and the batteries are all leaking all over the place and you got some of the juice on your hand, and the github issues page is just a bunch of people asking if the project is still alive yet. You really don't see that with the ones that kept it as simple as, and relying on as little as possible. My old stuff I wrote like that is still chugging along.

My only dependencies to track in this case are go, my webserver frontend (openbsd httpd) and the OS updates. Wow!

The applications I've written to this end aren't the kind of thing you can host on github pages, they're really dynamic and do all this image processing or handle tons of money a day. Turns out people throw more money around at stuff like that and this alone justifies the means.

Hell I know people who even do this in C or C++. That's right, web applications, usually in even more constrained environments like embedded or for game consoles. They get paid more than me, too.

But it's not an apples to apples comparison.

Generating static files has a smaller attack vector than running an executable on a server.

Keeping a service up and running over a long period of time is much more work than using generic static site hosting.

HTML that works today will likely still work in 10 years time, but a binary you compile today most likely won't, or at least, you'll have wanted to have changed up your server.

I feel you're looking a few levels into the decision tree of Hugo then using that level as the root of a decision tree to review all the other choices. There's not really a feasible way an individual can cut out a programming language or rebuild large portions of the stdlib like HTTPS and end up with something that's easy to maintain or reliable (or time feasible). There ARE easy ways an individual can generate static HTML without pulling in 1200 dependencies. Should there not have been a reasonable alternative to generating static pages that better aligned with the author's stated goals then sure, Hugo+Github would make just as much sense as pulling in the Linux, bash, and go dependencies did.

With GitHub I didn't catch that the reasons revolving around SLA/uptime percentages rather non-breaking change intervals and probability the service will exist usable as is in 10 years. Migrating to another host doesn't necessarily fix this unless there is a particular one to mention that will guarantee existence of the exact method of operation for the next decade and have a solid guarantee for the service to be offered as is for that long. The choices of Golang's stdlib and Linux provide reasonably solid choices in this regard as neither is going to change in a way that breaks deploying/running the site unless they _absolutely_ need to and both have about as big of support backing as one could reasonably expect to find so are unlikely to pull the rug out from the site on the premise of moving on to something newer and shinier like business offerings are often changed/deprecated for.

Certificates I definitely see a closer balance/argument on. On one hand the Github Pages way is really easy, they do it for you. On the other hand they are trying to avoid services that can disappear from them and are probably using ACME which seems to be pointed at Let's Encrypt right now. If for some reason Let's Encrypt did disappear though, which I'll be honest I'm on the side of that being less likely than some breaking change in the way an automated Github Pages hosted static site would function but I can see that being debated either way, at least it's not particularly hard to change the ACME provider for such a case. There may also be some personal sway on whether it's better to manage your own security certificates or not but I also can see that falling to either side depending on the person.

Regardless of choice the toolchain is going to have to be kept up to date to stay secure. There isn't any option to choose which is indefinitely secure and without security bugs.

> [...] a directory of compressed user page data in some proprietary format (including images) that was decompressed on-the-fly. Served over Apache with some CGI magic.

This is pretty neat. I believe that was done to save on server storage, and before client side gunzip was a thing?

Can you believe some of us crazy people still do this?

https://git.zx2c4.com/cgit/ cgit is the git repo frontend for projects like wireguard

https://undleadly.org has its source code in the sidebar for you to check out in C as well

https://learnbchs.org/ key is OpenBSD or other OS's (less easy to use) sandboxing if you're going to do this remotely safely - check this for more https://learnbchs.org/pledge.html

Woah I used to use this site a lot! I always wondered how things worked out for them

> The entire site was a single C source file littered with embedded HTML, a few separate HTML files for things like an FAQ, and a directory of compressed user page data in some proprietary format (including images) that was decompressed on-the-fly. Served over Apache with some CGI magic.

I know that it is a very slender hope but it would be cool to see the source of this.

It looks better than that, for sure, but only actually looks good if my phone is in landscape orientation.

In portrait, the section headers / titles are aligned right instead of center, which is odd, but the page title itself breaks onto two lines with the second aligned left.

There is also something odd about line breaks in general- I would swear that some lines are breaking early, as if the browser can't figure out that the first word of the next line absolutely looks like it could have fit. I actually switched to horizontal orientation just to see if the weird breaks weren't some odd artistic choice.

I've got to admit, though, that other than those complaints, I really do like the way there is content- just content.

I've tried hand rolling my own blog a number of times, but I always end up in the same position- I remember that I don't actually have anything to say that merits a standalone blog post that I actually would want anyone else to read.

I have built something similar and decided to simply use the embed[1] package which works well for this purpose.

[1] https://pkg.go.dev/embed

The source is at https://git.j3s.sh/j3s.sh/tree

I had a look since I was also curious and I am none the wiser as I don't see any embedding going on, but maybe I'm missing it.

Due to minifiers, mostly, no?

I should add that I've written my own Nim web stack on top of Jester. I'm getting it release ready. It integrates with a Flutter front-end engine that will be released first. https://nexusdev.tools/

> full control and minimum maintenance … contradicting

Not at all, every sheet of paper is like that.

For illiterates however it's true what you say.

The open challenge is: how to unclutter writing and educate literates!

Page content is bundled into the binary (or maybe not, it's not too clear from post)

There are plenty of good reasons to roll your own solution. A blog is about as risk-free of a situation as you will get when it comes to rolling your own.

It's not like the author is rolling their own encryption library.

This is how I write in chat, but not in emails or comments or readmes or more "permanent" things.

me too. this must have been studied linguistically somewhere? when i'm in lowercase mode i'll actually even go back and delete an accidental uppercase letter! so it's not just about laziness. maybe it has something to do with formality register? like how it can even be inappropriate to use a too formal register with a close friend, imagine if you suddenly called your spouse _mister_ or _misses_ smith!

Totally! I especially wish Titles With Every Word Capitalised would die