> i have very high and unusual standards,

Which was kind of funny TBH :)

If you are presented with the option of an abstraction – perhaps a library or framework, perhaps a service or API – is it "simpler" to use it or to not?

If you don't use it, and you build the alternative, you know more about how the system works as a whole, and therefore arguably it's simpler. But complexity is still introduced, and in some cases the abstraction layers still need to be built (but maybe not all of them).

If you do use it, you can consider the system to be simpler because you hide the complexity, and on the happy-path of usage that may be true, but the complexity still exists and you don't understand it because it's hidden. Arguably it's simpler, but it's easy to point to how it's more complex.

I've met engineers who strongly prioritise one or the other of these sorts, and to them that way is obviously simpler, but the problem is that both approaches are obviously simpler when you look at them in a certain way, you have to get past the obvious to realise that there are trade-offs.

> you should do this too!

Absolutely not :)

Maintainability is one of my core values too, down to doing my own bike maintenance, like you! But it is far from being #1 to such a degree that this would make sense for me.

The Framework laptop is a good divergence point for us. Whereas you continue to eke out 9s on the DIY side, I realize resilience by having a spare decade old ThinkPad lying around at all times on which I can run Linux and Neovim in a pinch, and trusting there will be a lot of sub-$100 ThinkPads in the future should that one break on me too. I carry around the bits of CS and mathematics needed to trust myself to write a slow, informal, bug ridden parser with Haskell's combinators from Markdown to HTML if I ever have to. I don't see that day coming any time soon.

I'd hire you if I could. You'd be the perfect counterweight to a great many folks who tilt in the opposite direction.

The author is honest with themself and earnest with the reader. They're unapologetically themself, and figuring out how to achieve their goals in ways that align with their values and bring them joy. If those values do not align with yours, that is okay. That is beautiful! Now you have a clue as to what path you might explore.

The article is kind and humble and authentic, and I think that the author and the article make the world a better place. Thank you for writing it, and thank you for sharing it.

The little HTML and CSS it uses actively renders the website worse. The poster is a troll.

> this script runs every minute on a cronjob, and rebuilds my site if the git repo has been updated.

He is pulling the git repo 525,600 times a year for the few commits he'll be making in that year... I guess that explains the "unusual" word?

I see a lot of very critical posts on here.

With all due respect… screw them.

Perhaps they may be right in their critiques, but as an industry we’re rapidly heading off into mass stupidity in order to follow a bunch of collective “ought to”s and “shoulds”. Many of which have the current validity of an urban myth.

What passes for “engineering” these days would be laughable if we weren’t actively building our future on it. My father was an aerospace engineer and I feel I can hear him rolling over in his grave at was passes for engineering in modern software development.

Yes, this is a comment section so everyone is free to comment. But personally it’s taken me 25 years in the industry to finally ignore all those chattering voices and actually do what I feel makes sense for those few opportunities where I can.

And on a personal site no less? That old “here’s to the crazy ones” line in the Apple commercial sure rings far from true. Given what the internet has become and that once startups are now literally the largest corporate behemoths on the landscape- it should not be a surprise.

Teddy Roosevelt’s quote about “the man in the arena” is so true these days.

I say rock on, OP, rock on…

My website, game engine, and webserver is one binary. The source has 1000 lines of C code. The binary has a size of 164k (I don't know why it is so damned big).

I included my own webserver. The existing servers add way too much (hidden) complexity.

You can check out the result, an interactive fiction game in German, here: http://vmd34232.contaboserver.net/ (no tracking, no ads, not commercial)

- The website is "one binary", but the deploy strategy involves compiling it instead of running a binary artifact

- Won't rely on github pages, but depends on external resource at openlibrary.org

- Writing your own stuff lets you take advantage of open standards, but the .html files in thoughts/ are structured as plaintext with a false file extension

- When people go this route, they usually try to cram everything into the initial page load. This has several static files served dynamically.

- The Golang code does not cache any responses, and does not store templates in memory.

- Several dependencies in the go.mod file, all of them seem unused?

Most importantly: No discussion about the technical benefits of the "single-binary" ethos compared to modern infrastructure.

It's my humble opinion that it's a great idea, and this is a poor example.

Unusual yes, but very low given the awful resulting design of the website that can't even present text to fit your screen properly

For my personal blog, I wrote a simple static site generator in Python. It converts markdown files into articles, an index page, and an RSS feed. The HTML templates and CSS are written by hand. It's required minimal maintenance over the years, and for the most part Just Works. After an edit, I rebuild the site on my local machine, and deploy with `rsync`.

I do have a couple of "dynamic" things hosted behind the same domain. For those, I configure nginx to reverse-proxy to a local service - which could be a python script, or anything else.

The only real advantage I can see to my setup, beyond personal preference, is that redeploys come with precisely 0 downtime. Presumably, if you're updating a binary, there's a brief moment where the old one shuts down and the new one starts up (unless you're doing some kind of clever reverse-proxy switchover)

Apparently accessibility isn’t one of them, given that increasing zoom level on Safari does jack shit.

I wonder if the author owns a car, and if he does, which?

Locking my Hugo build with something like Nix makes that comfortable. I can upgrade as I discover bugs but can always go back if it ain't broke. I do wish sometimes they would stop adding features.

What it's driving me to do in this same vein is build my own Hugo theme.

Also, tend to agree about dynamic sites vs JavaScript behemoths.

Disagree with the authors styling, and am a big fan of classless lightweight CSS, of which there are a number to choose from these days (I keep a list).

I think they missed the point of a static site generator: you "compile" your site once, and then you have static assets that never need any maintenance ever again (unless you decide to change something) and which can be served by anything, anywhere.

This approach seems to take the worst aspects of static site generators and dynamic sites and bundle them together: you now have a binary to maintain (that has to generate the HTML et al anyway) and you have the potential for security/other bugs and you now have extra CPU/RAM/IO load on your server and you need specific hosting that allows you to run your binary.

Don't get me wrong this is fun and all and nice that it works for the author, but I don't think it is a sensible way to make things simpler, more reliable, or easier maintain (the opposite in my mind).

I will agree that Hugo is terrible IME - so so so much complexity for very little benefit when compared to Jekyll et al.

Thanks to the odd scroll container i cannot zoom to a view where i do not have to side-scroll anymore.

[edit: with hindsight, looking at the other content on their site, I don’t think the date being April Fool’s day is particularly relevant.]

Where I do think the article misses the ball is on static vs. dynamic websites. If you need a dynamic website (for example, to display the user's IP), build a dynamic website. If you don't, build a static website. There really isn't another argument presented here beyond "some things you can't do with a static website", which is really just the fundamental tradeoff of a static site.

Anyways, a neat glimpse into a particular development philosophy that I will very likely never do but I will share with some similarly-minded friends :)

[1]: http://motherfuckingwebsite.com/

[1] https://news.ycombinator.com/item?id=26271117

Src code: https://github.com/Ono-Sendai/blog

You can do your fancy build process, single binary, whatever. The bottom line is if you want to call yourself a (good/strong/solid) web developer, your site needs to be accessible across all form factors.

I'm on mobile so I can't check, but I would bet this thing doesn't get even close to a good score on a tool like Lighthouse. Then the fact that some people are applauding OP and turning around making fun of "modern" software development (whatever that means) don't even realize they're part of perpetuating that problem (applauding sites which are missing key peices of accessibility and functionality)

This isn't really opinion or up for discussion either, this is quite literally the benchmark of living in our reality. We have accesibility guidelines and standards built over the years by hundreds of dedicated folks who worked hard to make those standards and guidelines clear - SO USE THEM! (meaning HTML5/CSS3/WCAG) Software is for humans, to be used by humans. Sure, I get the aspect that there is a bit of artistic freedom which OP has taken and by no means has to follow any guidelines at all. But this is definitively NOT a high standard or normal in any sense of what decent modern web development is.

Nope. Just a static HTML website... Cool...?

That said, compiling your web content into your server? That's a step too far. Data and the application that process that data are two very different things, and (imho) should remain separate.

While I don't have the same hesitations about depending on a small chain of open-source projects, I really didn't like the idea of caddy-exec despite my basic precautions, so I abandoned this approach until I can ponder it a bit more.

But if you want to make an apple pie from scratch, you first need to create a Universe, and you likely go for the simplest Universe that supports apple pies. The overall stack would be simpler (especially if you pursue simplicity and ease of understanding as a goal), but the last step, making the actual pie, may be more involved, and the taste of the resulting pie may be not top-notch. In exchange, you have a pie which you completely understand from first principles.

You can add stuff to make something easier to build or deploy (faster, more automated), while the addition makes the whole more complex (less understandable, harder to troubleshoot).

The author finishes by very explicitly saying do your own thing your way. Moreover, they suggest they're not happy using systems that they find understanding obscure/a burden.

I suggest reading beyond the opening paragraph.