Hacker News Reader

Comment by shubhamjain | Hacker News Reader

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.

View on HN

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.

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 :)

The slow part was mostly syntax highlighting and that was at least 3 years ago. Looking at 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 It is going to change name this week or next week though, gutenberg was not original enough :(

> gutenberg was not original enough :(

And I liked that name.

> 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?

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

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.

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.

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.

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.

Isn't the point of these frameworks not having to think about all of the nitty gritty details behind the scenes?

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.

I don't want to learn Go. I want a static site.

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

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

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

Edit: I found one (https://chesterhow.github.io/tale/). Beginning the switch soon.

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

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?

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.

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

What is the performance difference? All of them produce raw html and it's is served by static file servers right?

Performance during build, not serving the resulting files. I've seen people with really large Jekyll sites report build times of >40 minutes.

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/.gi...

https://about.gitlab.com/installation

IMO, GZ compression is really something that should be handled by your webserver and most do it easily. There is a jekyll-gzip plugin if for some reason you need it.

The content is static, and webservers like nginx support service gzip compressed equivalents if it finds it alongside the uncompressed ones. Might as well do that compression once rather than multiple times. If you're doing it just once, you can also realistically take the extra effort and use zopfli for further (albeit slower) compression.

Most of the major web server software caches the gzipped content. It only happens once.

Plus you can actually look at the files on the server without modification or piping them to gzip to check the files.

You can also elect not to gzip files smaller than MTU (1500 bytes) and stop wasting your and your client's time. Realistically it's often wasteful to gzip small files (below 5KB).

If you're worried about squeezing maximum compression out of your text files, then you're serving up too much stuff to clients anyway. You probably don't care about your users... just about your bloated page loading fast. Get rid of some ad garbage.

There are benefits to pre-compression:

https://theartofmachinery.com/2016/06/06/nginx_gzip_static.h...

That is what GitLab Pages expects, and because I can control my own pipeline with GitLab I am able to support multiple file formats that GitHub would not be able to support. It doesn't get any simpler than the example I provided.

I'll try and contain my derision towards serious conversations about hosting performance-sensitive content on GitHub/GitLab Pages. As explained in a separate comment, gziping _everything_ is wasting CPU.

If you just gzip from nginx, have content caching enabled (why don't you with static content?), and set a minimum size for gzipping, you have the best possible scenario and take a small hit on first requests of files until server-restart/cache-expiration.

> Stick with Jekyll, its robust, has support with github pages

Could you help me understand the value of this? It doesn't seem too hard for an SSG to provide documentation on what to put in a `.travis.yml` file.

There is 0 value. At some point there was some value, but not after the launch of services like Netlify.

In my experience, Netlify.com is 1000x better.

HTTPS, smooth integration with any SSG (including Hugo), any of the big git repos (GitHub, Gitlab, Bitbucket), great customer service, all for free.

> 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?

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

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.

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

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.

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.

Coming from Jekyll, Hugo theming was extremely daunting.

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

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.

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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com