11 ms·

If anyone is considering using Hugo, please account the tens of hours you will spend debugging its weirdness and magic. Yes, it's fast but it seems that ease-of

If anyone is considering using Hugo, please account the tens of hours you will spend debugging its weirdness and magic. Yes, it's fast but it seems that ease-of-use was its lowest of the low priority. How variables work is impossible to understand. So is creating new layouts. Every change, however minor, involves fighting hard until I give up and settle for a hack. The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing? Maybe, but I know how much time I spend on rendering when I am working with Flask + Jinja and how it's 10x worse with Hugo. Sadly, moving my blog way from Hugo would be too much work and I have to bear with it.

yoz-y 8y ago
I had quite good experience with it so far. I have migrated over from Middleman when the updating process become unbearable. I agree that doing new layouts is quite hit and miss. An extensive example using all possible variables would be quite welcome.
EarthIsHome 8y ago
Coming from Jekyll, Hugo theming was extremely daunting.
- swasheck 8y ago
  Agreed. I've started four themes and just give up. My blog lies stagnant because I'm not pleased with its appearance.
spython 8y ago
I found this a good introduction to variables and context in Hugo: https://regisphilibert.com/blog/2018/02/hugo-the-scope-the-context-and-the-dot/ https://regisphilibert.com/blog/2018/02/hugo-the-scope-the-c...
throwaway77384 8y ago
Do you come from a Go background? Because in my opinion, it starts to make sense if you understand what's going on behind the scenes with Go. Hugo always struck me as an SSG for developers who want something in between the super-easy to use, with zero experience and, well, starting from scratch with every site. Admittedly, even with a Golang background, I find there is quite a learning curve, so I wouldn't recommend it for anyone who is just trying to get their blog online.
- jandrese 8y ago
  Isn't the point of these frameworks not having to think about all of the nitty gritty details behind the scenes?
  - ams6110 8y ago
    You don't. I use Hugo, and haven't touched a line of go code. For me, setting it up, using one of the available templates, with a few tweaks, seemed very easy. But I haven't used other static generators so I'm not sure how Hugo compares.
- edem 8y ago
  I don't want to learn Go. I want a static site.
- kaushalmodi 8y ago
  > Do you come from a Go background? This is not directed to me but I'd like to chime in and say that one doesn't need to know Go language to write Hugo templates. I appreciate Go Templates even without knowing Go. It's quite simple: - If you don't want to learn the templating for a static site generator, use one of the readymade themes. - If you want to tinker with the themes or create your own themes, learn the templating language. There's no magic potion.
aorth 8y ago
Hugo has gotten very confusing as it has become more powerful. They are moving so fast and people are doing crazy stuff with it now! As the maintainer of a simple Hugo theme and a few simple blogs I can hardly keep up.
- kaushalmodi 8y ago
  I am not a web developer. I have been following Hugo development, and I see that a lot of new features are getting added. But if it's something that I don't care about (i18n, SASS support, archetypes update, etc) I just ignore and don't use the new features. I'm interested in knowing the overhead you are facing in keeping up. I just read the Release notes, and often find something I really wanted in the next update (if not everything in that update). Overall Hugo development is quite conservative about introducing backward incompatible changes. They do happen, but very rarely (sign of progress). I remember the last time that happened about a year back when Page Bundles got introduced.
gima 8y ago
Seconded. Cannot speak of other static site generators, as Hugo is the only I know, but it IS a pain to make anything that deviates from the golden path that's shown in the documentation.
bovermyer 8y ago
I've only run into a couple things that made me stop and think for a bit. For the most part, Hugo has just worked for me. Maybe we have different criteria for how a theme should be constructed.
Kagerjay 8y ago
Stick with Jekyll, its robust, has support with github pages, most number of themes for a static site generator, and the benefits you get from Hugo for performance are very small
- jlpom 8y ago
  What prevent Hugo from being supported by GitHub pages? I have never understood the "Jekyll integration" thing, you're just pushing static assets created by your static site generator to GitHub, so why would it be different from a generator to an other?
  - detaro 8y ago
    Github runs Jekyll for you, that's all integration there is. Meaning you do not have to push the generated files to update a Jekyll page hosted on there, only the source files.
  - Kagerjay 8y ago
    Github is based on ruby, so is jekyll, so its a frictionless setup that's free. You can use netlify but there's more setup to that than github imo. with github you can also have as many sites as you want, little unknown fact just make 100 organizations and you have 100 sites. Content is open to anyone though. But the option is still nice to have
- blocked_again 8y ago
  What is the performance difference? All of them produce raw html and it's is served by static file servers right?
  - detaro 8y ago
    Performance during build, not serving the resulting files. I've seen people with really large Jekyll sites report build times of >40 minutes.
- techntoke 8y ago
  Hugo has support for GitLab Pages and GZ compression, with really nice CI tools and an open source downloadable server version, unlike GitHub: https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gitlab-ci.yml https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gi... https://about.gitlab.com/installation https://about.gitlab.com/installation
applecrazy 8y ago
I know what you mean. I’ve been recently struggling with OpenGraph tags in Hugo. But there’s barely any documentation on how they work, so I had to hack something together that doesn’t work very well. I’m looking into Jekyll, but can’t find any themes as minimalistic as my current Hugo theme[1]. Any recommendations for a simple theme that doesn’t look like the default? [1]: https://applecrazy.github.io/blog https://applecrazy.github.io/blog Edit: I found one (https://chesterhow.github.io/tale/ https://chesterhow.github.io/tale/). Beginning the switch soon.
Keats 8y ago
Hugo is way too complex for me as well. Not to mention the awful awful Go template engine. I ended up writing my own static site generator which has a good chunk of the features of Hugo but focusing on ease of use rather than increasing the feature count. > The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. I have to disagree on that. My Pelican blog a few years back was taking several seconds to render vs milliseconds now and live reload is instant.
- LolWolf 8y ago
  Not sure what you mean, but my blog is currently generated by Pelican, and on dev server mode, live reload is unnoticeably fast! (To be fair, my blog is also relatively tiny, so it may be a consequence of this). On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
  - Keats 8y ago
    The slow part was mostly syntax highlighting and that was at least 3 years ago. Looking at https://github.com/getpelican/pelican/issues/1326 https://github.com/getpelican/pelican/issues/1326 it seems live reload as I mean it (without hard-refresh of the page) is only available through a plugin. > On the other hand, would love to take a peek at your static site generator, if there is such a difference :) Sure: https://github.com/Keats/gutenberg https://github.com/Keats/gutenberg It is going to change name this week or next week though, gutenberg was not original enough :(
    - epage 8y ago
      > gutenberg was not original enough :( And I liked that name.
- kaushalmodi 8y ago
  > awful awful Go template engine. I find it hard to understand what's so awful about Go Templates. Can you paste few examples of Go templating that you didn't like?
nicoburns 8y ago
It probably depends on how complex you are trying to make things. I'm using Hugo for my blog, and everything I've wanted to do (beyond creating the initial theme) has been a 5 minute task. Now that it includes SASS compilation it's perfect...
mmsimanga 8y ago
Its gets worse if like me you only blog once a year. It takes a while to figure out how to write a post let alone publish it. I can't imagine how long it would take to tweak the template. I too am sticking with Hugo, simple setup. I am not going to maintain a Drupal installation to host my blog. Makes one realise there are pros and cons with each technology.
- stadeschuldt 8y ago
  What do you mean by "It takes a while to figure out how to write a post"? With Hugo it is just adding a .md file inside your content folder, write the blog post and generate the blog with `hugo`. Or am I missing something here? The templating issue aside.
  - mmsimanga 8y ago
    It probably is just me. I find myself having to look up things like configuration for the menu, syntax highlighting. Hugo is a fantastic tool. I should just blog more often.
edem 8y ago
Absolutely agree. I tried Hugo after Jekyll and I run back to Jekyll screaming after touching Hugo. It is an implicit horrific mess with fucked up (il)logic.
hydrot3k 8y ago
I recently looking into different static site generators and I chose Hugo in the end because I found their documentation to be very clear. The Hugo framework can do a lot of things out of the box, without the need of plugins like most other frameworks. I saw this as an advantage, but I can understand you might want to go for something more simple if you don't need any of those features. I actually wrote an article about why I choose Hugo, on the site I made using Hugo: https://verummeum.com/blog/2018/09/02/how-verummeum-is-build/ https://verummeum.com/blog/2018/09/02/how-verummeum-is-build...
epage 8y ago
As someone who is maintaining one of the SSGs on this list, could you (or others) describe what these Hugo pain points are? I'm wanting to learn from our predecessors and avoid their mistakes.
- nickserv 8y ago
  Biggest problem for me is the template engine and its incoherence, followed by poor documentation. Also the lack of flexibility in content organization, although this seems like a common feature of static site generators, so I won't hold it (too much) against it. I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least. This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive. I'm looking into Gutenberg now, at least the template engine looks familiar enough.
  - kaushalmodi 8y ago
    > Biggest problem for me is the template engine and its incoherence, followed by poor documentation. What's wrong with the template engine? Also, before you switch to a different SSG, bring up the pain points in the documentation on the Hugo Discourse forum or as an issue in the HugoDocs GitHub repo. Please. > Also the lack of flexibility in content organization An example would help. What part of the content organization is inflexible. Of course there are some rules, else how will the SSG find the content consistently? But an example would help. (Atleast all the files don't have to be prefixed with date stamps.) > I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least. Examples please. What part is inaccessible? I have been using Hugo for 1+ year, and I am still going string on not learning Go (learning Nim instead, it's awesome!) > This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive. Typically when deploying SSG for a team, most of the team just contributes to the content (Markdown, for example), and few few folks handle the design of the site layout. So everyone doesnt even need to learn Go templates.
tmaly 8y ago
I ported my Wordpress blog to Hugo, yes it did take a bit of time for me to learn it. I created my own template, and now its super easy to write a new post. If your trying to do some form of email list, or e-commerce I would stick with Wordpress
maayank 8y ago
FWIW to others, I've gone from 0 to Hugo with no Go experience for a few personal sites and was pleasantly surprised by the ease of use.
kaushalmodi 8y ago
> tens of hours you will spend debugging its weirdness and magic. That's a very surprising comment, without any detail. Can you elaborate on what you found surprising and magical? > How variables work is impossible to understand. So is creating new layouts. Again, some details would help understand the real problem. [ It's agreed that you need to learn any new thing you'd like to use. ] I have used Hugo for more than a year now, and I don't see any reason to move away from it, as it is awesome! Once you understand Go Templates (this is awesome too. Coming from Emacs-Lisp, I can associate the Go Template syntax with it in some ways :D). > The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. I publish/update my site about a dozen times on days when I am updating my notes (which I publish to my site). It's a real boon to be able to save the content file, glance to the browser, and see it updated within that time. There is no exaggeration; it's that fast! It's difficult to take your complaints seriously if you update your site "only once"! > It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing? Which weird design choice? Which easy solution?

yoz-y 8y ago

I had quite good experience with it so far. I have migrated over from Middleman when the updating process become unbearable. I agree that doing new layouts is quite hit and miss. An extensive example using all possible variables would be quite welcome.

EarthIsHome 8y ago

Coming from Jekyll, Hugo theming was extremely daunting.

swasheck 8y ago
Agreed. I've started four themes and just give up. My blog lies stagnant because I'm not pleased with its appearance.

spython 8y ago

I found this a good introduction to variables and context in Hugo: https://regisphilibert.com/blog/2018/02/hugo-the-scope-the-context-and-the-dot/ https://regisphilibert.com/blog/2018/02/hugo-the-scope-the-c...

throwaway77384 8y ago

Do you come from a Go background? Because in my opinion, it starts to make sense if you understand what's going on behind the scenes with Go. Hugo always struck me as an SSG for developers who want something in between the super-easy to use, with zero experience and, well, starting from scratch with every site. Admittedly, even with a Golang background, I find there is quite a learning curve, so I wouldn't recommend it for anyone who is just trying to get their blog online.

jandrese 8y ago
Isn't the point of these frameworks not having to think about all of the nitty gritty details behind the scenes?
- ams6110 8y ago
  You don't. I use Hugo, and haven't touched a line of go code. For me, setting it up, using one of the available templates, with a few tweaks, seemed very easy. But I haven't used other static generators so I'm not sure how Hugo compares.
edem 8y ago
I don't want to learn Go. I want a static site.
kaushalmodi 8y ago
> Do you come from a Go background? This is not directed to me but I'd like to chime in and say that one doesn't need to know Go language to write Hugo templates. I appreciate Go Templates even without knowing Go. It's quite simple: - If you don't want to learn the templating for a static site generator, use one of the readymade themes. - If you want to tinker with the themes or create your own themes, learn the templating language. There's no magic potion.

aorth 8y ago

Hugo has gotten very confusing as it has become more powerful. They are moving so fast and people are doing crazy stuff with it now! As the maintainer of a simple Hugo theme and a few simple blogs I can hardly keep up.

kaushalmodi 8y ago
I am not a web developer. I have been following Hugo development, and I see that a lot of new features are getting added. But if it's something that I don't care about (i18n, SASS support, archetypes update, etc) I just ignore and don't use the new features. I'm interested in knowing the overhead you are facing in keeping up. I just read the Release notes, and often find something I really wanted in the next update (if not everything in that update). Overall Hugo development is quite conservative about introducing backward incompatible changes. They do happen, but very rarely (sign of progress). I remember the last time that happened about a year back when Page Bundles got introduced.

gima 8y ago

Seconded. Cannot speak of other static site generators, as Hugo is the only I know, but it IS a pain to make anything that deviates from the golden path that's shown in the documentation.

bovermyer 8y ago

I've only run into a couple things that made me stop and think for a bit. For the most part, Hugo has just worked for me. Maybe we have different criteria for how a theme should be constructed.

Kagerjay 8y ago

Stick with Jekyll, its robust, has support with github pages, most number of themes for a static site generator, and the benefits you get from Hugo for performance are very small

jlpom 8y ago
What prevent Hugo from being supported by GitHub pages? I have never understood the "Jekyll integration" thing, you're just pushing static assets created by your static site generator to GitHub, so why would it be different from a generator to an other?
- detaro 8y ago
  Github runs Jekyll for you, that's all integration there is. Meaning you do not have to push the generated files to update a Jekyll page hosted on there, only the source files.
- Kagerjay 8y ago
  Github is based on ruby, so is jekyll, so its a frictionless setup that's free. You can use netlify but there's more setup to that than github imo. with github you can also have as many sites as you want, little unknown fact just make 100 organizations and you have 100 sites. Content is open to anyone though. But the option is still nice to have
blocked_again 8y ago
What is the performance difference? All of them produce raw html and it's is served by static file servers right?
- detaro 8y ago
  Performance during build, not serving the resulting files. I've seen people with really large Jekyll sites report build times of >40 minutes.
techntoke 8y ago
Hugo has support for GitLab Pages and GZ compression, with really nice CI tools and an open source downloadable server version, unlike GitHub: https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gitlab-ci.yml https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gi... https://about.gitlab.com/installation https://about.gitlab.com/installation

applecrazy 8y ago

I know what you mean. I’ve been recently struggling with OpenGraph tags in Hugo. But there’s barely any documentation on how they work, so I had to hack something together that doesn’t work very well. I’m looking into Jekyll, but can’t find any themes as minimalistic as my current Hugo theme[1]. Any recommendations for a simple theme that doesn’t look like the default? [1]: https://applecrazy.github.io/blog https://applecrazy.github.io/blog Edit: I found one (https://chesterhow.github.io/tale/ https://chesterhow.github.io/tale/). Beginning the switch soon.

Keats 8y ago

Hugo is way too complex for me as well. Not to mention the awful awful Go template engine. I ended up writing my own static site generator which has a good chunk of the features of Hugo but focusing on ease of use rather than increasing the feature count. > The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. I have to disagree on that. My Pelican blog a few years back was taking several seconds to render vs milliseconds now and live reload is instant.

LolWolf 8y ago
Not sure what you mean, but my blog is currently generated by Pelican, and on dev server mode, live reload is unnoticeably fast! (To be fair, my blog is also relatively tiny, so it may be a consequence of this). On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
- Keats 8y ago
  The slow part was mostly syntax highlighting and that was at least 3 years ago. Looking at https://github.com/getpelican/pelican/issues/1326 https://github.com/getpelican/pelican/issues/1326 it seems live reload as I mean it (without hard-refresh of the page) is only available through a plugin. > On the other hand, would love to take a peek at your static site generator, if there is such a difference :) Sure: https://github.com/Keats/gutenberg https://github.com/Keats/gutenberg It is going to change name this week or next week though, gutenberg was not original enough :(
  - epage 8y ago
    > gutenberg was not original enough :( And I liked that name.
kaushalmodi 8y ago
> awful awful Go template engine. I find it hard to understand what's so awful about Go Templates. Can you paste few examples of Go templating that you didn't like?

nicoburns 8y ago

It probably depends on how complex you are trying to make things. I'm using Hugo for my blog, and everything I've wanted to do (beyond creating the initial theme) has been a 5 minute task. Now that it includes SASS compilation it's perfect...

mmsimanga 8y ago

Its gets worse if like me you only blog once a year. It takes a while to figure out how to write a post let alone publish it. I can't imagine how long it would take to tweak the template. I too am sticking with Hugo, simple setup. I am not going to maintain a Drupal installation to host my blog. Makes one realise there are pros and cons with each technology.

stadeschuldt 8y ago
What do you mean by "It takes a while to figure out how to write a post"? With Hugo it is just adding a .md file inside your content folder, write the blog post and generate the blog with `hugo`. Or am I missing something here? The templating issue aside.
- mmsimanga 8y ago
  It probably is just me. I find myself having to look up things like configuration for the menu, syntax highlighting. Hugo is a fantastic tool. I should just blog more often.

edem 8y ago

Absolutely agree. I tried Hugo after Jekyll and I run back to Jekyll screaming after touching Hugo. It is an implicit horrific mess with fucked up (il)logic.

hydrot3k 8y ago

I recently looking into different static site generators and I chose Hugo in the end because I found their documentation to be very clear. The Hugo framework can do a lot of things out of the box, without the need of plugins like most other frameworks. I saw this as an advantage, but I can understand you might want to go for something more simple if you don't need any of those features. I actually wrote an article about why I choose Hugo, on the site I made using Hugo: https://verummeum.com/blog/2018/09/02/how-verummeum-is-build/ https://verummeum.com/blog/2018/09/02/how-verummeum-is-build...

epage 8y ago

As someone who is maintaining one of the SSGs on this list, could you (or others) describe what these Hugo pain points are? I'm wanting to learn from our predecessors and avoid their mistakes.

nickserv 8y ago
Biggest problem for me is the template engine and its incoherence, followed by poor documentation. Also the lack of flexibility in content organization, although this seems like a common feature of static site generators, so I won't hold it (too much) against it. I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least. This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive. I'm looking into Gutenberg now, at least the template engine looks familiar enough.
- kaushalmodi 8y ago
  > Biggest problem for me is the template engine and its incoherence, followed by poor documentation. What's wrong with the template engine? Also, before you switch to a different SSG, bring up the pain points in the documentation on the Hugo Discourse forum or as an issue in the HugoDocs GitHub repo. Please. > Also the lack of flexibility in content organization An example would help. What part of the content organization is inflexible. Of course there are some rules, else how will the SSG find the content consistently? But an example would help. (Atleast all the files don't have to be prefixed with date stamps.) > I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least. Examples please. What part is inaccessible? I have been using Hugo for 1+ year, and I am still going string on not learning Go (learning Nim instead, it's awesome!) > This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive. Typically when deploying SSG for a team, most of the team just contributes to the content (Markdown, for example), and few few folks handle the design of the site layout. So everyone doesnt even need to learn Go templates.

tmaly 8y ago

I ported my Wordpress blog to Hugo, yes it did take a bit of time for me to learn it. I created my own template, and now its super easy to write a new post. If your trying to do some form of email list, or e-commerce I would stick with Wordpress

maayank 8y ago

FWIW to others, I've gone from 0 to Hugo with no Go experience for a few personal sites and was pleasantly surprised by the ease of use.

kaushalmodi 8y ago

> tens of hours you will spend debugging its weirdness and magic. That's a very surprising comment, without any detail. Can you elaborate on what you found surprising and magical? > How variables work is impossible to understand. So is creating new layouts. Again, some details would help understand the real problem. [ It's agreed that you need to learn any new thing you'd like to use. ] I have used Hugo for more than a year now, and I don't see any reason to move away from it, as it is awesome! Once you understand Go Templates (this is awesome too. Coming from Emacs-Lisp, I can associate the Go Template syntax with it in some ways :D). > The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. I publish/update my site about a dozen times on days when I am updating my notes (which I publish to my site). It's a real boon to be able to save the content file, glance to the browser, and see it updated within that time. There is no exaggeration; it's that fast! It's difficult to take your complaints seriously if you update your site "only once"! > It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing? Which weird design choice? Which easy solution?