3 ms·

Don't use Hugo. The maintainers are so detached from reality it's not even funny. The project is about 12 years old, has +80k stars on github and used in produc

by TeddyDD 6mo ago

Don't use Hugo. The maintainers are so detached from reality it's not even funny. The project is about 12 years old, has +80k stars on github and used in production by many. Despite that still no 1.0 version and they introduce breaking changes for no good reason. You website will break all the time. I made a mistake of creating few websites with it and now I have to rewrite them all in other SSG because I refuse to participate in this circus.

yoz-y 6mo ago
Eh. It’s written in go. I just built the binary, stuffed it in my repo and continued to use the same version for years. Then when I wanted to update I rewrote my whole theme from scratch, recompiled and now I’m set for years again.
- TeddyDD 6mo ago
  Good idea, sounds like the only sane way to use it.
- wiether 6mo ago
  Yes that's exactly what I did. I have a docker image with a given version of Hugo and I've been using it for years now. That's the beauty of building HTML: you don't HAVE to stay up to date to get security fixes.
  - andreashaerter 6mo ago
    Is there a reason for OCI images? It is just a binary? I have all used versions in ~/.local/bin/ ~/.local/bin/hugo0.145.0 ~/.local/bin/hugo0.148.0 ~/.local/bin/hugo0.149.0 ~/.local/bin/hugo0.150.0 [...] and a convenience symlink ~/.local/bin/hugo, pointing to my "production" version. I can easliy call whichever version I like with hugo<tab><tab>. What am I missing?
    - wiether 6mo ago
      It depends on your workflow I guess, but the advantages of having a Hugo version tagged in an image: - sharing it easily between computers/users (docker pull registry/image:tag) - having the appropriate binary version embedded in your code through a docker-compose in your repo - having custom aliases dedicated to hugo included (build/serve/run...) - using the exact same image in your CI/CD - not "polluting" your local computer with some more stuff
- cromka 6mo ago
  > Then when I wanted to update I rewrote my whole theme from scratch I think that's what OP complains about here
andreashaerter 6mo ago
Can't agree, even though I was also hit by breaking changes from time to time with my own templates. Because this has a BIG upside: I am very happy with Hugo and how they love to solve problems in detail and think through features to the end. Because of these frequent re-factorings and sometimes (!) breaking changes, it gets more elegant every year. And this is really not a production problem. As stated in the comments before, just don't upgrade if you don't want to / have no time yet. It is a self-contained static site generator without external dependencies. It won't break. And the security of an old Hugo binary is mostly a non-issue if you do not load remote content. And, if you have some time: Their changes are really well documented. The changelogs are really good. The main problem is sticking with an unmaintained template of a third party which breaks when you finally want to upgrade and don't want to fork / don't know when a an template update comes along. But that's the reason I write my own. It was worth the effort.

by TeddyDD 6mo ago

yoz-y 6mo ago

Eh. It’s written in go. I just built the binary, stuffed it in my repo and continued to use the same version for years. Then when I wanted to update I rewrote my whole theme from scratch, recompiled and now I’m set for years again.

TeddyDD 6mo ago
Good idea, sounds like the only sane way to use it.
wiether 6mo ago
Yes that's exactly what I did. I have a docker image with a given version of Hugo and I've been using it for years now. That's the beauty of building HTML: you don't HAVE to stay up to date to get security fixes.
- andreashaerter 6mo ago
  Is there a reason for OCI images? It is just a binary? I have all used versions in ~/.local/bin/ ~/.local/bin/hugo0.145.0 ~/.local/bin/hugo0.148.0 ~/.local/bin/hugo0.149.0 ~/.local/bin/hugo0.150.0 [...] and a convenience symlink ~/.local/bin/hugo, pointing to my "production" version. I can easliy call whichever version I like with hugo<tab><tab>. What am I missing?
  - wiether 6mo ago
    It depends on your workflow I guess, but the advantages of having a Hugo version tagged in an image: - sharing it easily between computers/users (docker pull registry/image:tag) - having the appropriate binary version embedded in your code through a docker-compose in your repo - having custom aliases dedicated to hugo included (build/serve/run...) - using the exact same image in your CI/CD - not "polluting" your local computer with some more stuff
cromka 6mo ago
> Then when I wanted to update I rewrote my whole theme from scratch I think that's what OP complains about here

andreashaerter 6mo ago

Can't agree, even though I was also hit by breaking changes from time to time with my own templates. Because this has a BIG upside: I am very happy with Hugo and how they love to solve problems in detail and think through features to the end. Because of these frequent re-factorings and sometimes (!) breaking changes, it gets more elegant every year. And this is really not a production problem. As stated in the comments before, just don't upgrade if you don't want to / have no time yet. It is a self-contained static site generator without external dependencies. It won't break. And the security of an old Hugo binary is mostly a non-issue if you do not load remote content. And, if you have some time: Their changes are really well documented. The changelogs are really good. The main problem is sticking with an unmaintained template of a third party which breaks when you finally want to upgrade and don't want to fork / don't know when a an template update comes along. But that's the reason I write my own. It was worth the effort.