11 ms·

Jeffgeerling.com has been migrated to Hugo

• unsungNovelty 9mo ago
  Welcome to the other side!!!
• dijit 9mo ago
  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 just don't post anymore, the site won't even compile. In theory I could use an old version of Hugo, but I have no idea when it broke, so how far do I go back? So, advice: submit the binary you used to generate the site to source control. I know git isn't the best at binary files, but I promise you'll thank me at some point.
  • unsungNovelty 9mo ago
    What kind of issues? I use my own private theme called Brahma which I wrote from scratch. I keep it simple and has been since 2019. I have barely had any issues. Given, mine is not sophisticated at all and simple by design. But curious what kind of issues pops up.
  • cadamsdotcom 9mo ago
    Sorry to hear it. Always sucks to not be able to tweak your own site. I’ve had amazing success debugging compile errors with Claude Code. Perhaps a coding agent could help you get it going again?
    • DrewADesign 9mo ago
      A pretty light-grey comment as I came across it. Maybe I’m missing something odious about it? People downvote this, but as a VERY skeptical AI skeptic, it’s exactly the sort of use case that makes sense to me: A) Low-stakes application with B) nearly no attack surface that C) you don’t use consistently enough to keep in your head, but D) is simple enough for an experienced software developer to do a quick sanity check on and run it to see if it works. Hell, do it in a sandbox if you feel better about it. If it was a Django/Node/rails/Laravel/…Phoenix… (sorry, I’ve been out of my 12+ years web dev career a short 4 years and suddenly realized I can only remember like 4 server-side frameworks/environments now) application, something that would run on other people’s devices, or really anything else that produces an executable output, then yeah fuck that vibe coding bullshit. But unless you’ve got that thing spitting out an SPA for you, then I say go for it.
    • dijit 9mo ago
      Yeah I feel like Claude Code is basically tailor made for a use-case like this. Where: * I have forked some public repository that has kept up with upstream (IE; lots of example code to draw from) * Upstream is publishing documentation on what's changing * The errors are somewhat google-able * Can be done in a VM and thrown away * Limited attack surface anyway. I think you're downvoted because the comment comes across as glib and handwavy (or not moving the discussion forward.. maybe?), and if it was a year ago I would probably argue against it.. but I think Claude Code can definitely help with this. It just didn't exist as it does in 2023~ or whenever it was that I originally started having issues. --- That said: it shouldn't be necessary. As others in this thread have articulated (well, imo) sometimes software is "done" and Hugo could be "done" software, except it's not; so the onus is on the operator to pin their definition of "done" version.. which is not what you'd expect.
      • cadamsdotcom 9mo ago
        > handwavy Yep. I missed the mark. OP seemed down and out about their blog being broken. So I was trying to put the idea across as not something to be afraid of. I should’ve just said it - LLMs are perfect for this use case.
        • dijit 9mo ago
          By OP do you mean the parent? I am the parent, and I am indeed down about it. :P It's a fair fix today like I mentioned, but back when it happened it wasn't available, and anyway, as I mentioned it shouldn't have been necessary.
  • smarx007 9mo ago
    How about specifying a version in the CI config? [0] Also, you know that you can do a binary search for the version that works for you? 0.154.0, 0.77.0, 0.115.0 ... (had to do it once myself) [0]: https://github.com/oslc-op/website/blob/9b63c72dbb28c2d3733c2480ac4a9bf1ffe4c278/.github/workflows/hugo.yml#L23-L26 https://github.com/oslc-op/website/blob/9b63c72dbb28c2d3733c...
    • dijit 9mo ago
      This is probably the smarter way actually. Alternatively there's apparently some nix flakes that have been developed. So, there's options. I just recommend pinning your version and being intentional about upgrades.
      • deleted 9mo ago
        [deleted]
      • tasuki 9mo ago
        > This is probably the smarter way actually. Oh definitely. How can you suggest adding a binary to a git repository? It's a bad idea on many levels: it bloats the repository by several orders of magnitude, and it locks you to the chosen architecture and OS. Nope, nope, nope.
        • 1718627440 9mo ago
          The issue with binaries is when they are large, change often, is often a duplication of information already present, and that you can't diff them. A program is neither large, it doesn't change often, is not duplicate information and you don't want to diff them. IMHO this idea is fine, this is not added the build artifact in every commit type of situation.
    • squirrellous 9mo ago
      Second this. Once I setup GitHub actions with Hugo (there’s one readily available), I rarely build the blog locally anymore. New article drafts become GH pull requests, and once ready they get merged and published. This also works on mobile well enough.
  • varun_ch 9mo ago
    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 builds with (or commit it to source control) and move on with my life. It’ll work as long as operating systems and CPU architectures/whatever don’t change too much (and in the worst case scenario, I’m sure the tech exists to emulate whatever conditions it needs to run) Some software is already ‘finished’ and there’s no need to update it, ever.
    • dgroshev 9mo ago
      There's a perfect term for this Patrick Dubroy coined: "cold-blooded software" https://dubroy.com/blog/cold-blooded-software/ https://dubroy.com/blog/cold-blooded-software/
      • bavell 9mo ago
        Love it. I need to keep this in mind for my personal projects!
    • eloisant 9mo ago
      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.
      • embedding-shape 9mo ago
        I guess my very own "niccup" (basically hiccup-in-nix) fits that (https://embedding-shapes.github.io/niccup/ https://embedding-shapes.github.io/niccup/), as you'll typically always include the library together with a strictly set version, so even when new versions are available, you'd need to explicitly upgrade if you want it.
  • ValentineC 9mo ago
    > 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 just don't post anymore, the site won't even compile. In theory I could use an old version of Hugo, but I have no idea when it broke, so how far do I go back? I've had the same issues as you, and yes, I agree that pinning a version is very important for Hugo. It's more useful for once-and-done throwaway sites that need some form of structure that a static site generator can provide.
  • ZoomZoomZoom 9mo ago
    > In theory I could use an old version of Hugo, but I have no idea when it broke, so how far do I go back? Had the same problem. Binary search is the latest trick people use. For SSG there's not much point in upgrading if everything works, and planned migration beats the churn in this case. You can just print a Hugo version in a HTML comment to track it in git.
    • mkl 9mo ago
      Binary search is a very old trick, going back to 1946 on computers, and probably thousands of years before that, since searching sorted lists goes back to at least ancient Babylon. https://en.wikipedia.org/wiki/Binary_search https://en.wikipedia.org/wiki/Binary_search
    • sejje 9mo ago
      There's a "git bisect" command waiting to get in the game
  • sylens 9mo ago
    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
    • ashishb 9mo ago
      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.
  • networked 9mo ago
    If you use an off-the-shelf binary for any tool, you can put the binary in `${project}/bin/`, add it to `.gitignore`, document the download URL in `README.md` or an install script, and commit the checksum in a project-wide `SHA256SUMS` file (or `B3SUMS`, etc.). It's like a lo-fi version of Git LFS.
  • the_mitsuhiko 9mo ago
    I moved to a AI maintained custom site generator and it’s ideal for my uses. I have full control over everything and nothing breaks me.
    • thijson 9mo ago
      I'm not sure if there should be a /s there. AI to me seems to be the antithesis of stable.
      • fluidcruft 9mo ago
        An AI-maintained tool is a different thing than using AI to generate the site.
      • the_mitsuhiko 9mo ago
        The AI only changes things when I want it to, and to my command. It's very stable.
        • overfeed 9mo ago
          You could also upgrade a static generator when you want to and equally achieve stability.
          • arjie 9mo ago
            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.
          • the_mitsuhiko 9mo ago
            They tend to change and when I want to do something that the generator does not do, I either need to hack it in (which might break) or i need to fork the generator.
    • 9mo ago
  • chrismorgan 9mo ago
    At least it’s practical to identify a specific version to use, and you can be reasonably confident it will work indefinitely. I remember that with the Hyde iteration of my site, somewhere along the way Hyde became impossible to install, and I was stuck with an existing installation, or a lot of effort to put it back together manually. Python packaging has improved a lot since then, so that I doubt that problem would apply on any new project, but it’s still far more plausible than in a language like Go or Rust. I maintained a personal fork of Zola for my site (and a couple of others), and am content to just identify the Git repository and revision that’s used. Zola updates broke my site a few times, quite apart from my patches not cleanly rebasing. I kept on the treadmill for a while, initially because of a couple of new features I did want, but then decided it wasn’t necessary. You don’t need to run the latest version; old is fine. —⁂— One piece of advice I would give for people updating their SSG: build your site with the old and new versions of the SSG, and diff the directories, to avoid regressions. If there are dynamic values, normalise both builds before diffing: for example, if you have timestamp-based cachebusting, zero all such timestamps with something like `sed -i 's/\?t=[0-9]+/?t=0/' **/*`. Otherwise regressions may be masked. I caught breakages a couple of times this way. Once was due to Zola changing how shortcodes or Markdown worked, which I otherwise might not have noticed. (Frankly, Markdown is horrible for things like this, and Zola’s shortcodes badly-designed; but really it’s mostly Markdown’s fault.)
  • nunez 9mo ago
    Run Hugo in Docker; in that instance, rolling forward/back is as easy as changing the tag in your Docker image.
    • dijit 9mo ago
      it's a Go programmer, so it's statically linked by default. No need for docker.
      • nunez 9mo ago
        It's useful if you want more control over how directories are mounted. I use this to hot-swap themes, for example.
  • mbreese 9mo ago
    I had a similar issue, but with Jekyll. I had a customized theme and some update along the way broke everything. So, I very much agree with a sibling comment about not needing to update static site generators and it’s not just a Hugo thing. Sadly, my site was also being hosted/generated by GitHub, so I had no real choice in the update matter. (I’m not sure if pinning would have helped.)
  • cxr 9mo ago
    It may be worth considering whether you need a native binary (and the ability to run it) for the job at all. A static site generator doesn't need to do anything that browsers from the last 10 years can't do; a static site generator is fundamentally a classic batch processing job that takes a collection of (mostly plain text) files as input, processes it, and then outputs something else (in this case, a collection of post-processed content for the site). If you encode the transformations that your desired SSG should perform by writing the processing rules as plain text source code that a browser is capable of executing (i.e., an "HTML tool" or something adjacent[1][2]), then you can just publish this "static site generator" itself as yet another page on your static site. To spell it out: running the static site generator to create a new post* doesn't need to involve anything more than hitting /new.html (or whatever) on the live site, clicking the button for the type=file input on that page, using the browser file picker to open the directory where the source to your static site lives, and then saving the resulting ZIP somewhere so the contents can be copied to whatever host you're using. 1. <https://simonwillison.net/2025/Dec/10/html-tools/ https://simonwillison.net/2025/Dec/10/html-tools/> 2. <https://crussell.ichi.city/pager.app.htm https://crussell.ichi.city/pager.app.htm> * in fact, there's nothing stopping you from, say, putting a textarea on that page and typing out your post right there, before the new build
  • monkey_monkey 9mo ago
    Why not go back to the version that your last post was published at, and stick with it?
    • dijit 9mo ago
      I can try that version, but it's entirely possible (and even: likely) that I was already using an old version of Hugo then; whatever was installed by my package manager - assuming I updated my machine somewhat recently. If I used MacOS then Hugo was probably very old, since I often forget to update brew packages and end up running very old software. But, that's what I thought to do first also. In the end, it becomes not worth the hassle, and spending time fixing it means that whatever I was going to write gets pushed out of my head, and it's very difficult to even bother. I'll probably go back to Svbtle.
  • ashton314 9mo ago
    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.
    • ashishb 9mo ago
      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).
  • 1dom 9mo ago
    I'm on your side. Nobody can point to a reason why it's a good idea for a site with any interactivity now. All the supporters here are all the same: "I had to do a whole bunch of mental gymnastics and compromises to get <basic server side site feature> but it's worth it!" But they don't say why it was worth it, beyond "it's easy now <after lots of work costs sunk>". When you try get to why they did it in the first place, it's universally some variation on "I got fed up with <some large server side package> so took the nuclear SSG route <and then had to eventually rewrite or get someone else's servers involved again>" Part of this is a me problem: a personal website should be owned by the person, IMO. A lot of people are fine to let other people own parts of their personal websites, and SSGs encourage that. What even is a personal website if it's a theme that looks like someone else's, hosted and owned on someone else's server - why not just use Facebook at that point?!
    • blacksmith_tb 9mo ago
      I was nodding along until your last paragraph - SSGs encourage letting other people own parts of your personal site, really? Sure, people bolt on Disqus or something, but otherwise I am not sure I follow the argument. Isn't part of the appeal of SSGs that all you have is a bunch of html/css/js that you can drop on any server anywhere (even a solar-powered RPi can serve a lot of requests[1])? 1: https://www.vice.com/en/article/this-solar-powered-low-tech-website-goes-offline-when-its-cloudy/ https://www.vice.com/en/article/this-solar-powered-low-tech-...
      • 1dom 9mo ago
        > Isn't part of the appeal of SSGs that all you have is a bunch of html/css/js that you can drop on any server anywhere (even a solar-powered RPi can serve a lot of requests[1])? This is the part I'm struggling with. That's the view I held from 2016 - 2024. Practically though, it's only true if you want a leaflet website with 0 interactivity. If you want _any_ interactivity at all (like, _any_ written data of any kind, even server or visitor logs) then you need a server or a 3rd party. This means for 99% of personal websites with an SSG, you need a real server or a 3rd party service. When SSGs first came around (2010 - 2015) compute was getting expensive, server sides were getting big and complex, bot traffic solutions were lame, and all the big tech companies started offering free static hosting because it was an easy free thing to offer. Compare this to now, 2026, it's apparently nothing special to handle hackernews front page on free or cheap compute. Things like Deno, Bun, even Go and Python make writing quick, small, modern server sides so much quicker, easier and safer. Cloudflare and or crowdsec can cover 99% of bot and traffic issues. It's possible to get multiple free multiple GB compute instances now. I didn't mean to imply there's some sinister plot of people maliciously encouraging people to use SSGs to steal their stuff, but that's the reality that modern personal webdev has sleepwalked into. SSGs were first sold to make things better performing and easier than things were at the time. Pretty much any "server anywhere" you own now will be able to run a handwritten server doing SSR markdown -> HTML now. So why force yourself to have to start entertaining ideas like making your visitors download multiple megabyte client side index files to implement search, or embedded iframes and massive JS external libraries for things like comment sections? Easier looking SSG patterns like that typically break all the stuff required to keep the web open and equal, like screen readers, low bandwidth connections and privacy. (Obviously SSR doesn't implicity solve these, but many of these things were originally conceived with SSR in mind and so are naturally more compatible). Ask anyone who's been in and out of web dev for more than 15 years to really critically think about SSGs in depth, and I think they'll conclude they offer a complete solution for maybe 1% of websites, but seem to be recommended in 99% of places as the only worthy way to do websites now. But when you pick it apart and try it, you end up in Jeff's position: statically rendered pages (the easy bit) and a TODO with a list of compromising options for basic interactivity. In 5 years time, he'll have complex SSG pipelines that's running almost 24/7, or a complex mesh of dependencies on external services that are constantly changing or trying to start charging him more to deal with his own creations. I really hope I'm wrong.
  • jesse_dot_id 9mo ago
    Sounds like a job for Claude Code to me.
  • PhilippGille 9mo ago
    > So, advice: submit the binary you used to generate the site to source control. I know git isn't the best at binary files, but I promise you'll thank me at some point. No need for the entire binary. Just put `go run github.com/gohugoio/hugo@vX.Y.Z "$@"` into a `hugo.sh` script or similar that's in source control, and then run that script instead of the Hugo binary. You'll need Go installed, but it's incredibly backwards compatible, so updating to newer Go versions is very unlikely to break running the old Hugo version.
  • theshrike79 9mo ago
    I had the same issue and I'm currently thinking whether it's easier to just Vibe Engineer my own static site generator with the exact features I need vs fighting with the hugo theme system. My needs for a site are pretty simple, so I might just go with the custom-built one to be honest. If it breaks, I can just go look in the mirror for the culprit =)
    • theshrike79 9mo ago
      EDIT: Just made my own. Claude + Opus and about 3-4 prompts. Looking at the comments here a common pain (that I share) is config and code drift, or just losing your config file and being unable to publish a new version without re-doing everything. I made a version where everything, including the HTML templates and CSS, is built in to a single static Go executable, no configuration files, everything is hard-coded. This way as long as I have the specific executable version and the source markdown files, I can deterministically replicate my blog output structure. The source is a directory in my Obsidian vault and the setup supports Obsidian-style front-matter
  • Expurple 9mo ago
    > advice: submit the binary you used to generate the site to source control. Or use HVM and submit the .hvm file (which is just a text file with the Hugo version that you use)
  • justinclift 9mo ago
    > In theory I could use an old version of Hugo, but I have no idea when it broke, so how far do I go back? Pretty sure the version of Hugo used to generate a site is included in metadata in the generated output. If you have a copy of the site from when it last worked, then assuming my above memory is correct you should be able to get the exact version number from that. :)
  • kybernetyk 9mo ago
    I have the same problem with Jekyll. I fixed my website for the Jekyll version I installed when I got this machine (in 2021). I dread the moment when I get a new computer and have to either try to install this particular version of Jekyll or to fix my website again. I just assumed static website generators would be stable but well, there's always something that breaks. Terrible user experience for someone who just wants to use the generator to generate a website vs. to tinker with it as a hobby. I'm in the process of porting my website to PHP ... but that project hasn't gone anywhere because currently everything works ;)
    • altbdoor 9mo ago
      In retrospect, Jekyll has been relatively stable recently. The last stable release was in January 2025, v4.4.1[1]. I've been using 4.3 to 4.4 without much issues, granted the sites I generate are simple. [1]: https://jekyllrb.com/news/ https://jekyllrb.com/news/
  • wiether 9mo ago
    I "solved" this issue by using a custom Docker image, both for writing/serving content locally, and for the CI. So I have a fixed Hugo version that I know works. And when I mean "solved", I actually never had the issue because, since I have no reason to upgrade Hugo, I never had to change my Docker image and never had the opportunity to risk breaking my theme.
• HelloUsername 9mo ago
  Out of interest: does anyone know what those three Safari extensions are on Jeff's screenshots? Edit: thx for answers below!
  • ctippett 9mo ago
    The </> looking icon is the Userscripts extension[1]. The one in the middle is for 1Password. The RSS looking icon I'm not sure about. [1] https://github.com/quoid/userscripts https://github.com/quoid/userscripts
  • mechanicum 9mo ago
    Maybe Subscribe with Reeder[0], 1Password[1], Userscripts[2]. The RSS and HTML icons are obviously fairly generic, so not 100% sure. [0]: https://reederapp.com https://reederapp.com [1]: https://1password.com https://1password.com [2]: https://github.com/quoid/userscripts https://github.com/quoid/userscripts
    • trvz 9mo ago
      I checked, it's not Reeder. Don't know what it is either, but I'd like to got off-topic and remember with fondness the time when you could subscribe to RSS feeds directly in Safari. Google Reader was replacable, a direct integration into the browser not.
      • geerlingguy 9mo ago
        The RSS button is https://rssdiscovery.app/ https://rssdiscovery.app/ And for a short time, RSS was the bee's knees across the entire Internet. Apple had the best support for it, and almost put NetNewsWire out to pasture, until they just removed all baked in RSS functionality, entirely :( But I use Reeder across Mac, iPad, and iPhone to keep up with feeds.
• ctippett 9mo ago
  Interesting. I'm currently looking to migrate from Hugo to Zola. Personally I feel like I grok the configuration and templating options for Zola better than I do for Hugo.
  • ramon156 9mo ago
    Note that I don't have a lot of requirements, but I love zola + gist. it works and I don't have to look at anything
  • open-sesame 9mo ago
    I moved my site from Jekyll to Zola after not really fancying Hugo. Have absolutely no regrets. Using Zola's GitHub actions to test/build and deploy to GitHub pages too.
• hesyiah 9mo ago
  Instead of committing the binary, I highly recommend using a .tool-versions file (if you use asdf or mise) or a Dockerfile with a pinned version.
  • supermatt 9mo ago
    What is the downside to committing the binary? Immunity to supply chain attacks and a faster build time?
    • surajrmal 9mo ago
      The best of both worlds is hosting the binary independently of git in some cloud storage and just have a script that fetches it (and set it in .gitignore). git itself doesn't like binaries very much and it will bloat your git clone speed/size if you update the binary ad it will effectively store all versions.
      • cxr 9mo ago
        The specific use case here is someone storing the binary because they're _avoiding_ updates.
      • sunnyday_002 9mo ago
        Or just use Git LFS.
• marcosscriven 9mo ago
  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.
  • coder543 9mo ago
    If you're okay with the images being on a CDN, why wouldn't you also be okay with the HTML and CSS also being on the CDN? Just fronting the entire static site with a pull-through CDN is an easy solution that doesn't require any complicated workflow.
    • marcosscriven 9mo ago
      I’m talking about integrating with GitHub. Publishing to Cloudflare for instance is fine, but where do you put the images between drafting and publishing? Or do you just check in images to GitHub and call it a day?
      • coder543 9mo ago
        I wasn't suggesting publishing to Cloudflare, just that if you're concerned about the complexity of the workflow of getting images into the CDN, simply fronting whatever host you're using with a CDN of some kind (which could be Cloudflare) will solve that. Usually you just store the images in the same git repo as the markdown. How you initially host the static site once generated is up to you. The problem with storing binaries in Git is when they change frequently, since that will quickly bloat the repo. But, images that are part of the website will ~never change over time, so they don't really cause problems.
        • marcosscriven 9mo ago
          [flagged]
          • 9mo ago
• maximgeorge 9mo ago
  [dead]
• ldoughty 9mo ago
  I had a similar push years ago, but I did take this approach once step further. For a similar reason Jeff mentions -- lower maintenance over time. I was frustrated that (because my posts are less frequent) changes in Hugo and my local machine could lead to changes in what is generated. So I attached a web hook from my websites GitHub repo to trigger an AWS Lambda which, on merge to main, automatically pulled in the repo + version locked Hugo + themes. It then did the static site build in-lambda and uploaded the result to the S3 bucket that backs my website. This created a setup that now I can publish to my website from any machine with the ability to edit my git repo. I found it a wonderful mix of WordPress-like ability to edit my site anywhere along with assurance that there's nothing that can technically fail* (well, the failure would likely, ultimately block the deploy, but I made copies of my dependencies where I could, so very unlikely). But really the main thing I love is not maintaining really anything here... I go months without any concern that the website functions... Unlike every WordPress or similar site I help my friends run.
  • geerlingguy 9mo ago
    Exactly; and I'm currently tinkering with different deployment options. One thing I may do to speed up the deploy is run the Hugo compilation on the server itself, so the only push that needs to happen for a new post is a few KB via git. A post-receive hook would then run Hugo and deploy into my public www dir.
• michalc 9mo ago
  > Beyond that, I've grown fond of 'sticking to the defaults' over the years. This resonates with me! Both in terms of things I use and things I make - I want them to "just work"
• dzink 9mo ago
  For long term stuff like a blog, nothing seems to beat static sites generated before deployment, instead of automated tools like Hugo. I tried Hugo years ago and some tiny config or update would suddenly expose all site variables to visitors, which was an incredible security risk. Wordpress and Drupal are a war zone of attacks - judging by the server logs of any of web site. These days you can custom write or design any page, click to build all menus, site maps, rss with something as simple as gulp, and move the files out via SFTP. Fast, performant, and secure.
  • loloquwowndueo 9mo ago
    Um. I don’t understand how Hugo is not a tool to create “ static sites generated before deployment”. I run Hugo to build all static content, check it locally, then push it via rsync.
  • loveparade 9mo ago
    Isn't static site generation exactly what hugo does?
    • plq 9mo ago
      Sure but you have to learn to use it. I'm saying that just have AI generate a SvelteKit project instead and you'll get better mileage out of it.
  • embedding-shape 9mo ago
    I'm fairly sure you're confusing Hugo with something else, Hugo is strictly a tool for building static websites. AFAIK, there are no features of Hugo which isn't for static website building.
  • deleted 9mo ago
    [deleted]
• a11ythrowaway 9mo ago
  the #fff on #000 gave me a migraine
  • snackbroken 9mo ago
    Consider not having your browser configured with prefers-color-scheme: dark.
• susam 9mo ago
  A few years ago, I decided to migrate my personal website to a Common Lisp (CL) based static site generator that I wrote myself. In hindsight, it is one of the best decisions I have made for my website. It started out at around 850 lines of code and has gradually grown to roughly 1500 lines. It handles statically rendering blog posts, arbitrary pages, a guestbook, comment pages, tag listings, per tag RSS feeds, a consolidated RSS feed, directory listing pages and so on. I have found it an absolute joy to maintain this piece of little 'machinery' for my website. The best part is that I understand every line of code in it. Every line of code, including all the HTML and CSS, is handcrafted. This gives me two benefits. It helps me maintain my sense of aesthetics in every byte that makes up the website. Further, adding a new feature or section to the site is usually quite quick. I built the generator as a set of layered, reusable functions, so most new features amount to writing a tiny higher level function that calls the existing ones. For example, last month I wanted to add a 'backlinks' page listing other pages on the web that link to my posts and it took me only about 40 lines of new CL code and less than 15 minutes from wishing for it to publishing it. Over the years this little hobby project has become quite stable and no longer needs much tinkering. It mostly stays out of the way and lets me focus on writing, which I think is what really matters.
  • Tomte 9mo ago
    Your wife’s Python version is quite impressive. It wouldn’t have occurred to me to do the simple thing and just do some string-replacement targeted at a narrow use-case instead of using a complicated templating engine.
    • embedding-shape 9mo ago
      > just do some string-replacement targeted at a narrow use-case instead of using a complicated templating engine. A neat little in-between "string replacements" and "flown blown templating" is doing something like what hiccup introduced, basically using built-in data structures as the template. Hiccup looks something like this: (h/html [:span {:class "foo"} "bar"]) And you get both the power of templates, something easier than "templating engine" and with the extra benefit of being able to use your normal programming language functions to build the "templates". I also implemented something similar myself (called niccup) that also does the whole "data to html" shebang but with Nix and only built-in Nix types. So for my own website/blog, I basically do things like this: nav = [ "nav" [ "h2" "Posts" ] [ "ul" (map (p: [ "li" [ "a" { href = "${p.slug}.html"; } p.title ] ]) posts) ] ] And it's all "native" Nix, but "compiles" to HTML at build-time, great for static websites :)
• seanwilson 9mo ago
  I really like Hugo as well. I've found it significantly faster than Jekyll which makes iterating much more pleasant and it's a single binary to download/run vs having to deal with Ruby and its package manager. I'm amazed there still isn't a decent free simple to host CMS solution with live page previews, a basic page builder, and simple hosting yet though. Is there one? There's https://demo.decapcms.org/ https://demo.decapcms.org/ (previously Netlify CMS) that you install and run via adding a short JavaScript snippet to a page. It connects to GitHub directly to edit content. You can running it locally or online, but you need some hosting glue to connect to GitHub. Netlify provides this but more options would be nice and I think they limit how many total users can connect on free plans. You can get something like a page builder set up via custom content blocks, but I don't think there's going to be a simple way to render live previews via Hugo (written in Go) in a browser. A JavaScript based SSG would help here, but now you have to deal with the JavaScript ecosystem. @geerlingguy Not a huge deal but noticed (scanning with https://www.checkbot.io/ https://www.checkbot.io/) if you click a tag in a post, it has an unnecessary redirect causing a speed bump that's easy to fix e.g. the post has a link to https://www.jeffgeerling.com/tags/drupal https://www.jeffgeerling.com/tags/drupal which then redirects to https://www.jeffgeerling.com/tags/drupal/ https://www.jeffgeerling.com/tags/drupal/.
  • geerlingguy 9mo ago
    I'll have to get those tag links fixed. That's especially odd as I think those links were the defaults from the Archie theme I based my site on!
    • seanwilson 9mo ago
      > That's especially odd as I think those links were the defaults from the Archie theme Internal redirects are really easy to miss without checking with a tool because browsers aren't noisy about it. Lots of sites have unnecessary redirects from URLs that use http:// instead of https://, www vs no-www, and missing/extra trailing slashes, where with some redirect configs you can get a chain of 2 or 3 redirects before you get to the destination page.
• cookiengineer 9mo ago
  I did a migration to markdown, too, but I decided to backport my previous nodejs code to Go, as I wanted the editor part to be still available as a standalone binary. This Christmas, I redesigned my website [1] into modular "middlewares" with the idea that each middleware has its own assets and embed.FS included, so that I can e.g. use the editor to write markdown files with a dynamic backend for publishing and rendering, and then I just generate a static version of my website for the CDN of choice. All parts of my website (website, weblog, wiki, editor, etc) are modular this way and just dispatch routes on a shared servemux. The markdown editor turned out to be a nice standalone project [2] and I customized the commonmark format a bit with a header for meta data like title, description, tags and a teaser image that is integrated with the HTML templates. Considering that most of my content was just markdown files already, the migration was pretty quick, and it's database free so I can just copy the files somewhere to have a backup of everything, which is also very nice. [1] https://cookie.engineer https://cookie.engineer [2] https://github.com/cookiengineer/golocron https://github.com/cookiengineer/golocron
  • cxr 9mo ago
    You know what's better than a standalone binary? Zero binaries. Previously: <https://news.ycombinator.com/item?id=29384788 https://news.ycombinator.com/item?id=29384788>
• deleted 9mo ago
  [deleted]
• 1dom 9mo ago
  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 dynamically generated from markdown - all an SSG pipeline adds is more dependencies and stuff to break. I know there's a fair few big nerd blogs powered by static sites, but when you really consider the full stack and frequency of work that's being done or the number of 3rd party external services they're having to depend on, they'd have been better by many metrics if the nerds had just written themselves a custom backend from the start. Jeff: I think you'll regret this. I think you'll waste 5 - 10 years trying to shoehorn in basic interactivity like comments, and land on a compromised solution. I also used and managed Drupal and Joomla before I went to SSGs, and then finally realised there's a sensible midpoint for the pain you're feeling: you write/run a simple server that dynamically compiles your markdown - good ol' SSR. It's significantly lighter, cheaper and easier than drupal, and lets you keep all the flexibility and features you need a server for. Don't take cave to the "self hosted tech was too hard so I took the easy route that forces me to also use 3rd party services instead" option. SSGing your personal site is the first step to handing it over to 3rd party services entirely IMO.
  • senko 9mo ago
    > 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, you're running a nextjs blog which requires server-side nodejs daemon so that your light/dark theme switch works as copy-pasted from stackoverflow. For blogs, number of reads vs number of comments or other actions that require a server is probably on the order of 100:1 or 1000:1, even more if many of the page loads are bots/scrapers. > SSGing your personal site is the first step to handing it over to 3rd party services entirely IMO. Why? Your interactive/feedback parts can be a 10-line script as well, running on the same site where you'd run Drupal, Joomla, Wordpress, Django, or whatever. Looks like Jeff plans to do exactly that: https://github.com/geerlingguy/jeffgeerling-com/issues/167 https://github.com/geerlingguy/jeffgeerling-com/issues/167
• qudat 9mo ago
  I know this isn’t quite the spirit of self hosting, but for people that aren’t ready to self they host can use https://prose.sh https://prose.sh which interops with Hugo. It’s a safe stepping stone into self hosting a blog for anyone who wants to get started slowly. prose is fully open source as well: https://github.com/picosh/pico https://github.com/picosh/pico It even has a Hugo migration repo for when users want to make the jump https://github.com/picosh/prose-hugo https://github.com/picosh/prose-hugo Alternatively you can use https://pgs.sh https://pgs.sh to deploy your Hugo blog using just rsync. The entire workflow starts and finishes in the terminal.
• Pacers31Colts18 9mo ago
  I ran Hugo when I launched my blog last year. I made 18 total posts. Probably 3/4 of those had issues when trying to publish due to issues with Hugo. Found it so frustrating.
  • IMSAI8080 9mo ago
    I recently moved off Hugo as well to a DIY Python static site generator for my own blog. The trouble I had was I found it frustrating to have to learn how to do something the Hugo way when I knew I could quickly code it in a language I was already familiar with.
• kmfrk 9mo ago
  What's the temperature on Pelican [https://getpelican.com https://getpelican.com] these days? Best Python SSG is mostly down to Hugo and Pelican as far as I can tell. I've always loved SSGs, but ActivityPub integration is also looking very attractive absent wider adoption of RSS.
  • TheChaplain 9mo ago
    I use pelican, with a bunch of self-made plugins, and it works very well. There's a few commits every month, so it's not a dead project.
  • BeetleB 9mo ago
    Happy Pelican user. If you know Python, it's the way to go.
    • imglorp 9mo ago
      Do you snapshot everything into a venv to insulate from upstream changes?
      • BeetleB 9mo ago
        No, but I probably should. To be frank, in using it for well over a decade I think something broke only once or twice. It's pretty stable and they give plenty of deprecation warnings.
  • rogerbinns 9mo ago
    Pelican is what I use, and it works well. I used to use Nikola, but gave up on that for two reasons. One was it was adding every possible feature which meant an ever growing number of dependencies which gets scary. And that is hard to use - eg how do you embed a youtube video becomes a trawl through documentation, plugins, arbitrary new syntax etc. But the biggest problem and one that can affect all the SSG is that they try to do incremental builds by default. Nikola of the time was especially bad at that - it didn't realise some changes mattered such as changes to config files, themes, templates etc, and was woolly on timestamps of source files versus output files. This meant it committed the cardinal sin: clean builds produce different output from incremental builds Pelican has kept it simple.
• nunez 9mo ago
  Welcome to the dark side, Jeff! I migrated to Hugo from WordPress in 2019: https://blog.carlosnunez.me/post/neurons-are-firing-again/ https://blog.carlosnunez.me/post/neurons-are-firing-again/ I built some automation that helps me test and deploy changes to S3 as well: https://github.com/carlosonunez/https-hugo-bloggen https://github.com/carlosonunez/https-hugo-bloggen. It's clunky but works for me! Feel free to fork/PR if you're interested, of course. It was a great move; I couldn't be happier. Running my blog is basically free (because nobody reads it, lol, but also because it's served by S3 and CloudFront and the # of monthly requests is still within Free Tier). At the time, some folks were questioning why I built this instead of moving to Netlify. I wanted control over how my sites were deployed and didn't want to pay some provider for convenience I knew I could build myself. Netlify got AI-pilled some time ago, which makes me feel vindicated in my position.
• daft_pink 9mo ago
  Just curious what you do with all the plug-ins. That’s the issue with the WordPress is replacing the plug-ins otherwise static sites are awesome
• nubinetwork 9mo ago
  I've been considering moving from WordPress to Hugo, mostly because I'm tired of updating it all the time, and the whole wpengine stuff. Was formatting old articles any difficult when moving to a new way of publishing?
• nickjj 9mo ago
  If you already write your posts in Markdown, it makes sense for sure. About a year ago I converted my 500+ post Jekyll blog to Hugo, overall it's been a net win but boy do I find myself looking up syntax in the docs a lot. Thankfully not so much nowadays but figuring out the templating syntax was rough at the time. Jeff, you don't have to set draft to false. You can separate your drafts into a different directory and use Hugo's cascade feature to handle it. Also you don't have to update the date in your frontmatter if you prefix the file with YYYY-MM-DD and configure Hugo to use that. Just a heads up, you didn't mention this in your post but Hugo adds a trailing slash for pretty URLs. I don't know if you had them before but it's potentially new behavior and canonical URL differences unless you adjust for that. When I did the switch from Jekyll to Hugo, I wrote a 10,000 word post with the gory details and how I used Python and shell scripts to automate converting the posts, plus covered all of the gotchas I encountered. There are sections focused on the above things I mentioned too: https://nickjanetakis.com/blog/converting-my-500-page-blog-from-jekyll-to-hugo https://nickjanetakis.com/blog/converting-my-500-page-blog-f...
  • tasuki 9mo ago
    > About a year ago I converted my 500+ post Jekyll blog to Hugo Why? I'm using Jekyll and been happy with it. What am I missing?
    • nickjj 9mo ago
      The blog post linked in my previous comment covers the why and everything else.
      • tasuki 9mo ago
        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 file names. This lets me cache them with nginx. I can’t not have that feature. Why?
• Group_B 9mo ago
  I've been using Hugo for the past 3 years. Biggest lesson I learned is to just fork the theme you're using and don't use submodules. There's no rush in keeping your theme up to date. Also you have complete control over the theme when its forked. I've only had stuff break on occasion when updating to a newer version of Hugo, had to change a couple things with the theme which did not take too long to fix. Curious to see how comments will be implemented though. Does not sound straightforward to add to a SSG.
  • geerlingguy 9mo ago
    This. A theme is individual to the site regardless... I almost migrated my Drupal theme over directly but gave up realizing I had so many views-view-view-field-data-field-body-formatted style classes lol. Some guides say to add submodules. I favor direct inclusion and just overriding layouts as you see fit.
• n8henrie 9mo ago
  Tried to migrate to Hugo from Jekyll multiple times and have bounced off every time. Don't really know Go very well, but better than Ruby, and used this as justification -- since dealing with Jekyll updates was sometimes a headache (I use GitHub Pages for free hosting and let them build things for me when I push updates). Instead I eventually just created an environment in nix that had compatible dependency versions to what GitHub uses and have been pleased since.
• philo23 9mo ago
  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 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. So over Christmas holiday I been playing around with NextJS SSG, and while it does basically everything I want (with some complicated caveats) I also can't help feel like I'm trying to use a oil rig to make a pilot hole when a drill would do just fine... Anyone got any recommendations on something somewhere in between 11ty and NextJS? I'd love something that's structured similar to 11ty, but using JSX with SSG that then gets hydrated into full blown client side components. The other thing I've been meaning to try is going back to something custom again, but built on top of something like Tempest [1] to do most the heavy lifting of generating static pages, but obviously that wouldn't help at all with client side components. [1]: https://tempestphp.com https://tempestphp.com
  • necubi 9mo ago
    I moved my startup’s marketing site and blog from NextJS to Astro, and I’m happy with it. It’s in that middle ground—focused on primarily static sites but with the ability to still write bits of backend logic as needed. I found it hard to get next to reliably treat static content as actually static (and thus cacheable), and it felt like a huge bundle of complexity for such a simple use case.
  • ValentineC 9mo ago
    > 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 https://github.com/laktek/punch
• zikani_03 9mo ago
  This has inspired me to move my personal blog to Hugo aswell. I have been using Hashnode[0] for the past few years and while it's okay, they recently automatically deleted one of my blog posts which was written in my local language, Chichewa and was one of my popular amongst, even non-developers. Ironically, my company's blog and websites are built with Hugo. [0]: https://code.zikani.me https://code.zikani.me
• markstos 9mo ago
  I also wanted to spend less time maintaining my personal blog and more time writing for it. After trying custom software, WordPress and Jekyll, I'm happily using Ghost for the blog which hits a sweet spot of features and simplicity, with the plugin and security update headaches of WordPress.
• amelius 9mo ago
  Does it run on an RPi now? :)
  • geerlingguy 9mo ago
    It'll be so much easier next time I try! Though I did run it on Drupal off a Pi cluster for a few weeks as an experiment.
• plq 9mo ago
  My impression is that tools that grew complex only because they want to serve every use case under the son got obsoleted by AI, and static site generators like Hugo are a good example. Today, if I were setting up a blog to host just some text and images, a vibe-coded SvelteKit project using the static adapter[1] would easily solve every single problem that I have. And I would still be able to use the full power of the web platform if I need anything further customized. [1]: https://svelte.dev/docs/kit/adapter-static https://svelte.dev/docs/kit/adapter-static
• eptcyka 9mo ago
  Where did the family crest go?
  • geerlingguy 9mo ago
    Haven't decided if it'll pop back on the bottom or not yet; I just forgot about it until yesterday, and when I was stuffing it down there it looked out of place, so I gave up for now. Or I might stick it somewhere else, as an easter egg, we'll see!
• j1elo 9mo ago
  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.
  • subset 9mo ago
    In particular, Hugo overhauled its templating system in [v0.146](https://gohugo.io/templates/new-templatesystem-overview/ 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/ 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.
    • chiengineer 9mo ago
      [flagged]
• bschmidt25003 9mo ago
  [dead]
• oooyay 9mo ago
  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.
  • chiengineer 9mo ago
    Looking for general feedback on my astro project i built with copilot in vs code https://tariqdude.github.io/Github-Pages-Project-v1/visual-showcase/ 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
    • oooyay 9mo ago
      There's a lot of bugs, but the design looks neat.
• cromka 9mo ago
  Slightly off topic, but is there any sensible way yet to federate a statically-geenerated website to Mastodon? Ideally being able to show the comments on the website. I get the staticness doesn't really help here, but I imagine this is a problem that will find a cleaver solution eventually?
  • treesknees 9mo ago
    You can use Hugo to generate/update an rss feed of your blog. There are tools to post rss feed updates as posts on mastodon. As far as comments, I’ve seen it done, but as far as I know it’s a bunch of custom code. One example I found: https://andreas.scherbaum.la/post/2024-05-23_client-side-comments-with-mastodon-on-a-static-hugo-website/ https://andreas.scherbaum.la/post/2024-05-23_client-side-com...
    • cromka 9mo ago
      Thank you, i'll have a look
• wolvoleo 9mo ago
  Ah nice, welcome Hugo Geerling!
• jlrubin 9mo ago
  one thing i've found, is that i've regretted not blogging more via PDFs. This is because Google Scholar treats PDFs as first class citizen, so your Important blog posts can get added to academia. maybe a plugin can solve this particular gripe...
• aqeelat 9mo ago
  Can someone explain why not just use Wordpress? I don’t fully get the idea of SSGs.
  • klysm 9mo ago
    SSGs are a lot cheaper and easier to serve.
  • toast0 9mo ago
    Wordpress is fine for what it is, but it's also an upgrade treadmill. You can kind of bypass that by letting the php process running wordpress have access to write to the code directory so wordpress can upgrade itself, but then your php process has access to write to the code directory. A blog is mostly a static site that changes occasionally, a static site genetator is a much better fit. Caveat: comments, but personally, I don't want to moderate, and the WordPress site I administerred for work didn't want comments either (but even with them disabled, somehow new comments and trackbacks got into the database). When I finally got approval to turn our blog into a mostly static site, it was joyous, and the server(s) stopped burning cpu like nobody's business to serve the same handful of pages. We used PHP to manage serving translated blog entries, but it's not that much slower than a fully static file when your PHP logic is dead simple and short.
• gn4d 9mo ago
  Why Hugo over Astro for something lightweight? Or why not even bashblog? Seems like a strange choice to go with Hugo if he's aiming for lightweight and speed.
  • wink 9mo ago
    Just by being written in JS/TS and using node I suppose keeping it running is a task of its own (or keep a node_modules folder of 500MB) - compared to a hugo binary that will most probably work on any linux or mac for the next 10 years. (I see what you're getting at but Astro has to be _the worst_ example. I have migrated off hugo to my own SSG but I don't hate it)
    • gn4d 9mo ago
      Ah, makes sense, good points! I keep focusing so much on lightweight for the end user out of the box, and Astro still has been rather "lightweight" serverside for me (but good point how for a small device, a bloaty node_modules could be a pain point), though I also haven't used any large-scale deployments. Thanks for the reply! Are you rolling your own SSG now?
      • wink 9mo ago
        Migrated 3.5y ago - https://f5n.org/blog/2022/switching-to-nextgen/ https://f5n.org/blog/2022/switching-to-nextgen/ after getting fed up with having to do a migration. At that time it was "make my hugo setup run, and remove 90% of the features I don't need" - but I couldn't tell you how much I have diverged, it's really not a lot of code (or dependencies, but I did not reimplement the hard parts, e.g. markdown and templating)
        • gn4d 9mo ago
          Cool! Thank you for the replies! And best of luck!
• dweller42 9mo ago
  I can relate to Jeff's "I'm not a Ruby developer". I used to have a Jekyll blog myself and migrated to Hugo. I feel Hugo is much simpler.
• angelfangs 9mo ago
  Found Hugo templating to be unnecessarily hard and confusing. After toying with Python using string.replace and Pandoc, I finally settled for Eleventy with Nunjucks.