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

161–170 of 253 posts

Re: Jeffgeerling.com has been migrated to Hugo

#161

Post by nickjj »

tasuki wrote: post #151
nickjj wrote: post #138

Earlier quoted context omitted.

The blog post linked in my previous comment covers the why and everything else.

Right, I missed that! > That gives near instant live reload when writing posts which makes a huge difference from waiting 4 seconds. Mhm. Why? I can write all of my post and look at it only afterwards? Perhaps if there's a table or something tricky I want to check before. But normally, I couldn't care less about the reload speed. > I use that plugin because it digests your assets by adding a SHA-256 hash to their fil…

> Mhm. Why? I can write all of my post and look at it only afterwards?

My site has a fixed max width which is what most tablets or desktops will view it as.

Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim.

Seeing exactly what my site looks like while writing lets me see these things as I'm writing and having a fast preview enables that. Waiting 4 seconds stinks.

> Why? [asset digesting and cache busting with nginx]

It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server. If their browser already has the exact CSS or JS file cached locally, this allows you to skip a server side call to even determine if the asset can be served locally or needs an update from the server.

The concept of digesting assets with infinitely long cache header times isn't new or something I came up with. It's been around for like 10+ years as a general purpose optimization.

Re: Jeffgeerling.com has been migrated to Hugo

#162

Post by j1elo »

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 interesting.

Hugo is very well established, but at the same time it's known for not caring too much about introducing breaking changes; I think any given project with that age should already respect its great userbase and provide a strong guarantee of backwards-compatibility with the inputs/outputs that it decides to draw for itself, not revolve in an eternal 0.x syndrome calling itself young enough to still be seeking its footing in terms of stability but I digress... and in fact, Hugo hasn't been great in that regard. Themes and well functioning inputs do break with updates, which here in this house of mine, is a big drawback.

Re: Jeffgeerling.com has been migrated to Hugo

#163

Post by arjie »

eloisant wrote: post #39
varun_ch wrote: post #13

Earlier quoted context omitted.

I’ve slowly grown to realize there’s some software you just don’t need to update. A static site generator (almost certainly) won’t have security issues as long as you control the input and the output is just a bunch of static files. Unless the new version of the software includes some feature I need, I can be totally fine just running an old version forever. I could just write down the version of the SSG my site buil…

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.

I use `mise` to manage all my tool versions[0] and committing the version file to the repo is sufficient for later use. https://mise.jdx.dev/

0: not all, I use cargo to manage the rust toolchain

Re: Jeffgeerling.com has been migrated to Hugo

#164

Post by arjie »

overfeed wrote: post #158
the_mitsuhiko wrote: post #58

Earlier quoted context omitted.

The AI only changes things when I want it to, and to my command. It's very stable.

You could also upgrade a static generator when you want to and equally achieve stability.

That's somewhat untrue. Personal software only moves to your constraints. Shared software moves to others' as well. I use Mediawiki for my site (I would like others to be able to edit it) and version changes introduce changes in more than the sections I care about.

Re: Jeffgeerling.com has been migrated to Hugo

#165

Post by fn-mote »

brycewray wrote: post #156
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.

> 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? For Hugo, there is Hugo Version Manager (hvm)[0], a project maintained by Hugo contributor Joe Mooring. While the way it works isn't precisely what you described, it may come close enough. [0]: https://github.com/jmooring/hvm

I hate to say it, but even the existence of this tool is a danger sign.

I say this as someone who uses Hugo and is regularly burned (singed) by breaking changes.

Pinning your version is great until you trip across a bug (usually rendering, in my case) and need to upgrade to get rid of it. There goes a few hours. I won’t even mention the horror of needing a test suite to make sure the rendering of your old pages hasn’t changed significantly. (I ended up with large portions of text in a code block, never tracked the root cause down… probably something to do with too much indentation inside a bulleted list. It didn’t render that way several years before, though.)

Re: Jeffgeerling.com has been migrated to Hugo

#166

Post by ashishb »

marcosscriven wrote: post #9

I like Hugo, but I’ve not found a nice workflow to automatically put the images on a CDN. I was thinking of making a GitHub action that uploaded the image from a given branch, deleted it, set the URL, and finally merged only the md files to main.

Why not put the whole site behind CDN?

Re: Jeffgeerling.com has been migrated to Hugo

#167

Post by seanwilson »

1dom wrote: post #122
seanwilson wrote: post #94

Earlier quoted context omitted.

I've used https://lunrjs.com/guides/getting_started.html briefly and it has lots of options for things like different fields, complex queries, fuzzy searching and wildcards. Didn't notice anything specific about dates but you could always add date as a field then filter out a date range manually at the end. I'm sure there's better libraries now as well.

We've gone from SSGs for ease, speed and reduced resources, to talking about implementing search with multiple megabyte client side indexes and hundereds of thousands of prerendered search result pages. When does this become 1 step forward with the SSG and 2 steps back with search solutions like this?

You don't pre-render the search pages. You generate some search index files on the build step (something like a map of keywords to matching post URLs), and then client side JavaScript requests the search index files it needs on demand and generates the search results on the page. For a modest blog, I think the compressed index can be a few 100K. A single large image can be bigger than that.

Nothing is perfect, but the above is really simple to host, is low maintenance, and easy to secure.

Re: Jeffgeerling.com has been migrated to Hugo

#168

Post by ashishb »

ashton314 wrote: post #135
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…

I've been burned by this a few times and now I have the Hugo binary in source control. I had to dig through the releases a little bit to find the version that didn't break everything.

Yeah. That's one flip side.

Hugo-papermod, the most famous Hugo theme, doesn't support the latest 10 releases of Hugo.

So, everyone using it is locked into using an old version (e.g. via Docker).

Re: Jeffgeerling.com has been migrated to Hugo

#169

Post by ashishb »

sylens wrote: post #27
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…

I recently broke my Hugo blog theme when updating and had to migrate to a whole new theme, it was a pain. From now on I probably won't update it

That should definitely improve.

Right now, you are pretty much locked into the theme (and it's version) when you set up your website for the first time.

Post reply on HN