Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jeffgeerling.com has been migrated to Hugo

jeffgeerling.com

Post reply on HN
Print view View original

171–180 of 253 posts

Re: Jeffgeerling.com has been migrated to Hugo

#171

Post by subset »

j1elo wrote: post #162

I'd love to see more reasoning about the decision process to select one static site generator in particular. There are a ton of them, and for sure a bunch of them that we could call "the big ones" so anyone deciding to migrate will probably go through the aame process of evaluating and choosing. i.e. Hugo, Eleventy (11ty), Jekyll, and a couple more are the most known. Seeing Jeff's decision process could be interesti…

In particular, Hugo overhauled its templating system in [v0.146](https://gohugo.io/templates/new-templatesystem-overview/) which resulted in build fails for my blog when I upgraded.

As of today, the [docs](https://gohugo.io/templates/lookup-order/) still haven't been fully adjusted to reflect the new system:

> We did a complete overhaul of Hugo’s template system in v0.146.0. We’re working on getting all of the relevant documentation up to date, but until then, see this page.

I don't mind breaking changes, but it'd sure be nice if the documentation reflected the changes.

Re: Jeffgeerling.com has been migrated to Hugo

#172

Post by oooyay »

I've used a lot of static site generators including Hugo and Jekyll. Frankly, I find Go templating and other Jinja style templating an exhausting mental exercise. I don't like it for the same reason that I don't like using Go templating for server side rendering; I would prefer to have an entirely different code base that runs my frontend that only does frontend logic. Components just make that much sense and template partials will never compete with the flexibility of components. That was how I landed on Next.js and MDX for my blog. I get Markdown and I get components where Markdown just won't do and it's all statically compiled.

Jeff's approach of writing a separate comments application is interesting. I've seen people reuse GitHub issues to accomplish that, but that limits your audience participation to GitHub. The other obvious choice, I think, is a headless CMS. I'll be curious to see where he goes with it.

Re: Jeffgeerling.com has been migrated to Hugo

#173

Post by jesse_dot_id »

dijit wrote: post #3

I made the jump to Hugo too (from a managed service: svbtle) a long time ago, but I'll be really honest... I regret it. I decided to use an off-the-shelf theme, but it didn't quite meet the needs and I forked it; as it so happens Hugo breaks userland relatively often and a complex theme like the one I have requires a lot of maintenance. Like.. a lot . Now I can't really justify the time investment of fixing it so I j…

Sounds like a job for Claude Code to me.

Re: Jeffgeerling.com has been migrated to Hugo

#174

Post by chiengineer »

_heimdall wrote: post #91
1dom wrote: post #52

I think this is silly, and it's a hill I'm willing to die on. I wrote this in a comment yesterday, and Jeff has fully confirmed/vindicated this in his post: SSGs are good for static sites with no interactivity or feedback. If you want interactivity or feedback, someone (you or a 3rd party service provider) is going to have to run a server. If you're running a server anyway, it seems trivial to serve content dynamical…

This is where I've found Astro to really shine. Most people reached for it because of the whole "islands of interactivity" concept, but IMO the ability to easily build a mostly static site with server APIs when needed is a the killer feature. I manage multiple Astro sites and eventually they have all needed at least a few small server endpoints. Doing that with Astro is very simple and it can be done without making t…

Ive reposted my personal demo Astro project with zero eyes

Is anyone willing to give feedback on it whatsoever?

https://tariqdude.github.io/Github-Pages-Project-v1/visual-s...

Re: Jeffgeerling.com has been migrated to Hugo

#175

Post by chiengineer »

oooyay wrote: post #172

I've used a lot of static site generators including Hugo and Jekyll. Frankly, I find Go templating and other Jinja style templating an exhausting mental exercise. I don't like it for the same reason that I don't like using Go templating for server side rendering; I would prefer to have an entirely different code base that runs my frontend that only does frontend logic. Components just make that much sense and templat…

Looking for general feedback on my astro project i built with copilot in vs code

https://tariqdude.github.io/Github-Pages-Project-v1/visual-s...

I ran into all these problems just last summer trying to launch something new so I said fk it went all in on a overkill demo just to see whats possible

Re: Jeffgeerling.com has been migrated to Hugo

#176

Post by chiengineer »

subset wrote: post #171
j1elo wrote: post #162

I'd love to see more reasoning about the decision process to select one static site generator in particular. There are a ton of them, and for sure a bunch of them that we could call "the big ones" so anyone deciding to migrate will probably go through the aame process of evaluating and choosing. i.e. Hugo, Eleventy (11ty), Jekyll, and a couple more are the most known. Seeing Jeff's decision process could be interesti…

In particular, Hugo overhauled its templating system in [v0.146]( https://gohugo.io/templates/new-templatesystem-overview/ ) which resulted in build fails for my blog when I upgraded. As of today, the [docs]( https://gohugo.io/templates/lookup-order/ ) still haven't been fully adjusted to reflect the new system: > We did a complete overhaul of Hugo’s template system in v0.146.0. We’re working on getting all of the re…

[flagged]

Re: Jeffgeerling.com has been migrated to Hugo

#177

Post by ValentineC »

philo23 wrote: post #116

A long while ago I wrote a very simple static site generator for personal site, mainly just to play around with using GitHub/Cloudflare pages to host my personal site. Then a couple of months ago I started comparing the big SSG tools after wanting something a bit less held together with duct tape... after a lot of experimenting I settled on 11ty at the time, but I really don't enjoy writing Liquid templates, and writ…

> after a lot of experimenting I settled on 11ty at the time, but I really don't enjoy writing Liquid templates, and writing reusable components using Liquid felt very clumsy. I just wish it was much easier to use the JSX based templates with 11ty, but every step of the way feels like I'm working against the "proper" way to do things.

Doesn't Eleventy support most of the common old-school templating languages? I once converted a site using Mustache from Punch [1] to Eleventy.

Eleventy is great, and in some ways I prefer it to Hugo if build time isn't an issue. At least templates don't break, like most of the comments here say.

I eventually redid the site from scratch (with a bit of vibecoding magic back when v0 got me into it) with Astro.

[1] https://github.com/laktek/punch

Re: Jeffgeerling.com has been migrated to Hugo

#178

Post by stusmall »

Cyph0n wrote: post #146
eloisant wrote: post #39

Earlier quoted context omitted.

Is there any static site generator where you specify the version you use, and the launcher will simply run the old binary that you want? Like most build systems work, for example when you set a "rust-version" in Cargo.toml and only bump it when you explicitely want to. This way it will still use the older version on a fresh checkout.

Just wrap it in a Nix flake and define a devshell. The entire config won’t exceed more than ~10 lines of Nix. Once setup, all you need to do is: $ nix develop —-command hugo regenerate $ # version is pinned by flake.lock The beauty of this approach is that it extends to almost any CLI tool you can think of :)

This is the way. This is how I do it with mine but use channels instead of flakes because I'm a giant curmudgeon.

My devshell can be found here and is dead simple: https://github.com/stusmall/stuartsmall.com/blob/main/defaul...

I used Zola for my SSG and can't think of the last breaking change I've hit. I just use the pattern of locked nix devshells for everything by default. The extra tools are used for processing images or cooklang files.

Re: Jeffgeerling.com has been migrated to Hugo

#179

Post by dvdkon »

1dom wrote: post #96
senko wrote: post #60

Earlier quoted context omitted.

> If you're running a server anyway, it seems trivial to serve content dynamically generated from markdown. Until you have enough visitors or evil AI bots scraping your site so that it crashes, or if you're using an auto-scaling provider, costs you real money. The problem isn't in markdown→HTML conversion (which is pretty fast), it's that it's a first step in adding more bells and whistles, and before you know it, yo…

> Until you have enough visitors or evil AI bots scraping your site so that it crashes, or if you're using an auto-scaling provider, costs you real money. There's been multiple blog posts on HN from people who've received a hug of death and handled it fine with basically free or A couple of gigs of RAM and 2 cores can take viral posts and the associated bots. 99% of personal websites never go viral either. > The prob…

You seem to think an SSG is some burden that people put up with due to sunk cost fallacy, but I don't see why.

The Markdown-to-templated-HTML pipeline code is the same whether it runs on each request or on content changes, so why not choose the one that's more efficient? Serving static HTML also means that the actually important part of my personal webpage (almost) never breaks when I'm not looking.

Re: Jeffgeerling.com has been migrated to Hugo

#180

Post by susam »

1dom wrote: post #149
susam wrote: post #126

Earlier quoted context omitted.

I have always had a comments section on my website since its early days. Originally, my website was written as a set of PHP pages. Back then, I had a PHP page that served as the comment form. So later when I switched to Common Lisp, I rewrote the comment form in it. It's a single, self-contained server side program that fits in a single file [1]. It runs as a service [2] on the web server [2], serves the comment and…

Nice! So you weren't forced to rewrite a comments solution when you shifted to an SSG, you just coincidentally had to do them at the same time? It looks like you did exactly what Jeff did: got fed up with big excessive server sides and went the opposite way and deployed and wrote your own minimal server side solutions instead. There's nothing wrong with that, but what problem were you solving with the SSG part of tha…

> [...] what problem were you solving with the SSG part of that solution? Why would you choose to pregenerate a bunch of stuff which might never get used any time anyone comments or updates your website, when you have the compute and processes to generate HTML from markdown and comments on demand?

I was not trying to solve a specific problem. This is a hobby project and my choices were driven mostly by personal preference and my sense of aesthetics.

Moving to a fully static website made the stack simpler and more enjoyable to work with. I did not like having to run a local web server just to preview posts. Recomputing identical HTML on every request also felt wasteful (no matter how trivially) when the output never changes between requests. Some people solve this with caching but I prefer fewer moving parts, not more. This is a hobby project, after all.

There were some practical benefits too. In some tests I ran on a cheap Linode VM back in 2010, a dynamic PHP website could serve about 4000 requests per second before clients began to experience delays, while Nginx serving static files handled roughly 12000 requests per second. That difference is irrelevant day to day, but it matters during DDoS attacks, which I have experienced a few times. Static files let me set higher rate limits than I could if HTML were computed on demand. Caching could mitigate this too, but again, that adds more moving parts. Since Nginx performs extremely well with static files, I have been able to avoid caching altogether.

An added bonus is portability. The entire site can be browsed locally without a server. In fact, I use relative internal links in all my HTML (e.g., '../../foo/bar.html' instead of '/foo/bar.html') so I can browse the whole site directly from the local filesystem, from any directory, without spinning up a web server. Because everything is static, the site can also be mirrored trivially to hosts that do not support server-side programming, such as https://susam.github.io/ and https://susam.codeberg.page/, in addition to https://susam.net/. I could have achieved this by crawling a dynamic site and snapshotting it, which would also be a perfectly acceptable solution. Static site generation is simply another acceptable solution; one that I enjoy working with.

Post reply on HN