I wonder why it seems nobody wants to use Hugo. Smashing Magazine appears to be happy with it and they tooted about their experience with Hugo multiple times.
Instead, everyone chooses Gatsby, Next or another javascript based framework of this week.
I've tried to use Hugo multiple times and absolutely hated it.
It's in a very weird spot in terms of difficulty/productivity.
It's got a very steep learning curve, with a lot of complexity. Things like how it resolves certain values involve following multiple steps that may or many exist in your project and require knowing framework specific rules and terminology. Stuff like which template is used is so complicated. All the other stuff about taxonomy and archetypes, etc also get really confusing.
But all that complexity translated to very little productivity (for me at least). I struggled with setting up beautiful templates, and found all the extra configuration cumbersome because the simple things I wanted to do was buried under all this other crap I had to learn about.
And when I did need advanced features, I didn't want to use hugo. Or things that I did need, were core aspects that were difficult to do with hugo because it's core configuration is so bloated.
Not to mention all the problems with versions and documentation that I had when one at least one of the occasions I tried it.
I looked into using Hugo and some other SSGs and eventually decided to hack together my own minimal version in Python.
It doesn't do much, it doesn't handle Markup (because that's not how I want to work), and it probably took less time than really mastering someone else's SSG.
As many other comments are saying, because it's Go.
The majority of developers who use static-site generators professionally are frontend developers. Their language of choice is javascript or typescript. And if many are complaining about the inconvenience of writing graphql plugins — in javascript! — for Gatsby, imagine the annoyance of having to write the logic for your build step in an entirely different language. In Go, or in Ruby for that matter. It isn't fun. You can't easily use the skills you developed in javascript to tweak the behavior of the static site generator to your liking. You can't extend its behavior by writing a custom plugin. You feel constrained, and at the mercy of Hugo maintainers. It's very disheartening.
However. There is a fantastic alternative both to Hugo (by being javascript-based) and to Gatsby/Next (by not requiring React for the simplest hello world). Its name is Eleventy, and it is beautiful!
Hugo is a single executable - it doesn't require any knowledge of Go itself. Granted, you have to be familiar with the templating syntax to add build-time logic to the website, but I believe that syntax is common across many other static site generators as well.
Yes, if you want to add logic in addition to the templating primitives provided by default, then being able to write code into the source pages will be of great help. However I think that when such a level of dynamism is required, then one can start debating the utility of a static generator in the first place.
I built a data intensive website with Hugo and it’s horrible. Template engine is very bad. Hard to write reusable small functions (string manipulation, array manipulation, data extraction, mapping one form of data to other, filtering etc.). The fact that statements can’t be multiline is ridiculous.
Coming from Hakyll which just gives you all the power of Pandoc and a programming language, it was really a chore to work with Hugo. I’ll never use it again.
Hugo is really, really good at what it does. I run a number of static blogs on it, including that of my startup [0] and my personal blog [1]. However, for many purposes, a completely static setup like the one that Hugo offers is surpassed by the reactive capabilities of Next.js/Gatsby/Nuxt, etc.
For larger, more complex sites, javascript frameworks make more sense, and offer far more functionality for building a web-app.
Plus, you can generally take the the dynamic generators and dial them down to a purely static build for sites that genuinely aren't using client-side features, but you can't go in the opposite direction.
I never tried Gatsby, but I tried Hugo. I like Go, so I searched for a Hugo-template I liked and build some documentation for my project. Then I took a break from the project and when I wanted to update the documentation a few months later (minor changes), I spend about 2 days just bringing my content in sync with the updated template. What a horrible experience.
Maybe I was doing something wrong or the template author, but actually I am thinking about my best options currently, because I am 100% sure, I don't want to go through that mess again. Even building plain HTML pages by hand would have been a lot easier for me than finding out why the updated template didn't compile anymore.
I use two pieces of backend software: Django and Hugo. Django is hugely more complex and I have considerably more experience with Hugo... And yet I run into far fewer problems and get stuff done faster with Django.
Hugo has exactly one thing going for it compared to other static site builders: it's fast. I have about 100 pages now and they build in <1second.
Aside from that, it's a pain to work with. The documentation is sparse but serviceable, but the community on GitHub and Discourse leaves a lot to be desired. Grumpy and unresponsive and much more inclined to close your issue or tersely tell you to read the docs than provide help or admit you have a valid feature request/bug report.
I would disagree with your complexity assessment there. Hugo has so much inferred logic and "magic" that working out why your pages aren't showing correctly can take hours before you notice the silly mistake you made. You're just slapped in the face until it starts working.
Django is of course a lot bigger, with many more moving parts, but it's much more explicit, Nd the documentation is superb; you're running a lot quicker.
For those who want to like Hugo, but can't stand the templating language: there's also Zola (https://github.com/getzola/zola), a superb static site generator, with built-in Sass compilation, written in Rust.
Dunno, but I'm going to take a stab in the dark at the possible incentive structure:
(1) No amateur is especially proud of setting up a static site, because it either seems easy as expected or it wasn't easy and they don't feel like trumpeting that.
(2) Professional web developers went into web development because they like featureful JavaScript, so they don't really see the appeal of static sites.
(3) Some big % of professional designers went into design because they wanted to design complex user experiences, and so they push for things that require JavaScript.
(4) Website owners like metrics, so they want a bunch of JavaScript to track user engagement and whatnot.
I have seen good results from Hugo. It is easy and typically works. Good for a small business website.
Because Hugo doesn’t solve the dynamic problem. It also is not flexible enough for composing content. If you look at the Sentry docs you can see that it depends on the flexibility of the graphql system to feed shared content to different parts of the documentation.
I wrote a frankenstein script to stitch together Hugo + Netlify + GitLab to automate the structure of my 300-something domain names, see e.g. https://awesome.id, https://every.id and https://debut.id.
For the content (not done yet), I want humans to write it, but haven't found a scalable approach.
After spending two weeks with Gatsby for my current project, I ditched it for Hugo and it was GREAT.
Not only Gatsby feels complicated for simple things, but doesn't offer the same level of flexibility as Hugo does. And it also has the most appreciated benefit of not having to battle with the js ecosystem. Hugo just works.
> Once you figure out how to really effectivity use it you can be productive and build out some huge websites and it's fast as hell.
I don't doubt that, but a site that is a) huge, and b) doesn't require interactivity seems rather niche to me. SSG's really shine to me on small sites, and to some degree mid-sized ones. Code documentation is a good example, where I made some new library at work and now I want to dump some nice documentation somewhere. It's only a few pages, all I need is a way to convert Markdown to HTML in a semi-pleasing format, and have the SSG handle creating an index or ToC sidebar so people can navigate.
Hugo sucks for this. The templating language is Go's, which I don't care for much, and doesn't seem to be very widely used outside of Hugo. So now I have to learn a DSL just to use Hugo, which is unlikely to be useful for anything else, ever.
The templating language also seems to change constantly. I feel like every time I update Hugo, I have to go find a new theme, because now I get 10,000 warnings that they're going to redo the whole template API, and like 7 things my theme is doing aren't compatible with their new API. Of course, someone will say that I can build my own theme. And you're right! If I want to go become an expert in this esoteric DSL so I can figure out how to iterate over pages to build my ToC. Plus now that I'm building a theme, part of me starts wondering if it wouldn't be easier to just hand-write the HTML.
These NodeJS site generators are at least an order of magnitude easier to work with. I get code completion, so I don't have to try to remember all the various built-in and custom macros. I get unit tests, so when I change something in my theme, I can test it. I find that it's easier to genericize things from tutorials as well. If I want to add a navigation sidebar to all my pages, I just need a tutorial that shows me where I hook into the base page template (i.e. add a customizePageTemplate() call when you instantiate the renderer or something). From there I can use code completion and docs to figure out what I have access to to do the things I want. Again, that's because it's a familiar domain. If I want to do the same thing in Hugo, I pretty much need a tutorial specifically dedicated to customizing the base page templates. Even if someone tells me where to customize it, I end up having issues because the things you can access inside Hugo depend on where you are in the rendering pipeline, and Hugo's templating language doesn't make it easy to tell what you have access to at the moment.
I do admire their speed, but I have had effectively no situations where I have a site that is both large enough to be worth learning the DSL, and simultaneously doesn't require anything that Hugo makes difficult.
I like Hugo. I've been using it since 0.17. I've forgotten if I found getting started with it easy or hard. But since then it has been a relatively smooth ride. No node or javascript baggage, fast build times, single executable - what is not to like?
preommr|5 years ago
It's in a very weird spot in terms of difficulty/productivity.
It's got a very steep learning curve, with a lot of complexity. Things like how it resolves certain values involve following multiple steps that may or many exist in your project and require knowing framework specific rules and terminology. Stuff like which template is used is so complicated. All the other stuff about taxonomy and archetypes, etc also get really confusing.
But all that complexity translated to very little productivity (for me at least). I struggled with setting up beautiful templates, and found all the extra configuration cumbersome because the simple things I wanted to do was buried under all this other crap I had to learn about.
And when I did need advanced features, I didn't want to use hugo. Or things that I did need, were core aspects that were difficult to do with hugo because it's core configuration is so bloated.
Not to mention all the problems with versions and documentation that I had when one at least one of the occasions I tried it.
TheOtherHobbes|5 years ago
It doesn't do much, it doesn't handle Markup (because that's not how I want to work), and it probably took less time than really mastering someone else's SSG.
azangru|5 years ago
The majority of developers who use static-site generators professionally are frontend developers. Their language of choice is javascript or typescript. And if many are complaining about the inconvenience of writing graphql plugins — in javascript! — for Gatsby, imagine the annoyance of having to write the logic for your build step in an entirely different language. In Go, or in Ruby for that matter. It isn't fun. You can't easily use the skills you developed in javascript to tweak the behavior of the static site generator to your liking. You can't extend its behavior by writing a custom plugin. You feel constrained, and at the mercy of Hugo maintainers. It's very disheartening.
However. There is a fantastic alternative both to Hugo (by being javascript-based) and to Gatsby/Next (by not requiring React for the simplest hello world). Its name is Eleventy, and it is beautiful!
alphachloride|5 years ago
Yes, if you want to add logic in addition to the templating primitives provided by default, then being able to write code into the source pages will be of great help. However I think that when such a level of dynamism is required, then one can start debating the utility of a static generator in the first place.
knuthsat|5 years ago
Coming from Hakyll which just gives you all the power of Pandoc and a programming language, it was really a chore to work with Hugo. I’ll never use it again.
sebmellen|5 years ago
For larger, more complex sites, javascript frameworks make more sense, and offer far more functionality for building a web-app.
Two different purposes, IMO.
[0]: https://blog.assembl.net [1]: https://blog.slm.space
crooked-v|5 years ago
arendtio|5 years ago
Maybe I was doing something wrong or the template author, but actually I am thinking about my best options currently, because I am 100% sure, I don't want to go through that mess again. Even building plain HTML pages by hand would have been a lot easier for me than finding out why the updated template didn't compile anymore.
todotask|5 years ago
gherkinnn|5 years ago
I know React and Next let me solve my problems faster.
That’s it.
(Aside: Both Gatsby and Next have been around for a while and will be for the foreseeable future. So not a flavour of the week.)
LunaSea|5 years ago
esperent|5 years ago
Hugo has exactly one thing going for it compared to other static site builders: it's fast. I have about 100 pages now and they build in <1second.
Aside from that, it's a pain to work with. The documentation is sparse but serviceable, but the community on GitHub and Discourse leaves a lot to be desired. Grumpy and unresponsive and much more inclined to close your issue or tersely tell you to read the docs than provide help or admit you have a valid feature request/bug report.
oliwarner|5 years ago
Django is of course a lot bigger, with many more moving parts, but it's much more explicit, Nd the documentation is superb; you're running a lot quicker.
vsupalov|5 years ago
quickthrower2|5 years ago
roenxi|5 years ago
(1) No amateur is especially proud of setting up a static site, because it either seems easy as expected or it wasn't easy and they don't feel like trumpeting that.
(2) Professional web developers went into web development because they like featureful JavaScript, so they don't really see the appeal of static sites.
(3) Some big % of professional designers went into design because they wanted to design complex user experiences, and so they push for things that require JavaScript.
(4) Website owners like metrics, so they want a bunch of JavaScript to track user engagement and whatnot.
I have seen good results from Hugo. It is easy and typically works. Good for a small business website.
the_mitsuhiko|5 years ago
weego|5 years ago
That has a strong smell of losing focus on your core principles and obsessing over adoption stats at any cost
wiradikusuma|5 years ago
For the content (not done yet), I want humans to write it, but haven't found a scalable approach.
speedgoose|5 years ago
Fiahil|5 years ago
Not only Gatsby feels complicated for simple things, but doesn't offer the same level of flexibility as Hugo does. And it also has the most appreciated benefit of not having to battle with the js ecosystem. Hugo just works.
kilroy123|5 years ago
Once you figure out how to really effectivity use it you can be productive and build out some huge websites and it's fast as hell.
curryst|5 years ago
I don't doubt that, but a site that is a) huge, and b) doesn't require interactivity seems rather niche to me. SSG's really shine to me on small sites, and to some degree mid-sized ones. Code documentation is a good example, where I made some new library at work and now I want to dump some nice documentation somewhere. It's only a few pages, all I need is a way to convert Markdown to HTML in a semi-pleasing format, and have the SSG handle creating an index or ToC sidebar so people can navigate.
Hugo sucks for this. The templating language is Go's, which I don't care for much, and doesn't seem to be very widely used outside of Hugo. So now I have to learn a DSL just to use Hugo, which is unlikely to be useful for anything else, ever.
The templating language also seems to change constantly. I feel like every time I update Hugo, I have to go find a new theme, because now I get 10,000 warnings that they're going to redo the whole template API, and like 7 things my theme is doing aren't compatible with their new API. Of course, someone will say that I can build my own theme. And you're right! If I want to go become an expert in this esoteric DSL so I can figure out how to iterate over pages to build my ToC. Plus now that I'm building a theme, part of me starts wondering if it wouldn't be easier to just hand-write the HTML.
These NodeJS site generators are at least an order of magnitude easier to work with. I get code completion, so I don't have to try to remember all the various built-in and custom macros. I get unit tests, so when I change something in my theme, I can test it. I find that it's easier to genericize things from tutorials as well. If I want to add a navigation sidebar to all my pages, I just need a tutorial that shows me where I hook into the base page template (i.e. add a customizePageTemplate() call when you instantiate the renderer or something). From there I can use code completion and docs to figure out what I have access to to do the things I want. Again, that's because it's a familiar domain. If I want to do the same thing in Hugo, I pretty much need a tutorial specifically dedicated to customizing the base page templates. Even if someone tells me where to customize it, I end up having issues because the things you can access inside Hugo depend on where you are in the rendering pipeline, and Hugo's templating language doesn't make it easy to tell what you have access to at the moment.
I do admire their speed, but I have had effectively no situations where I have a site that is both large enough to be worth learning the DSL, and simultaneously doesn't require anything that Hugo makes difficult.
alphachloride|5 years ago
detaro|5 years ago
onion2k|5 years ago