Hacker News new | comments | show | ask | jobs | submit login

Maybe Hugo has improved, but when I switched our static website from Jekyll over to Hugo, there was a lot to be wished for.

One of the problems is that it's not easy to integrate Hugo into any other build process. For better or worse, many website build tools right now are in JavaScript (npm, bower, gulp, grunt, yo, etc.). And on the flip side, Hugo does not do any static resource processing. So for our site, we needed to have Grunt tasks fetch third-party libraries, compile the JS and CSS, perform lint checks, and finally put files into the correct location so that Hugo could then be called to build the final site. Now, to be fair, Jekyll core does not do any of this for you either, but at least there are plugins in Jekyll [0], and integration of custom build scripts becomes a bit smoother.

This brings me to my second pain, which is shortcodes [1]. It is the closest Hugo has to plugins. Hugo completely disallows writing raw HTML in Markdown content (the cited reason is it "is in complete opposition to the intent of using a bare-bones format for our content and utilizing templates to apply styling for display"). It makes sense, and I'd use a system that separates raw content from more complicated code. But when you start needing to put dynamic content in your site, shortcodes in Hugo specifically are extremely unflexible. You're stuck using the Go template library that underlies Hugo, which gives you very limited information about the page being rendered.

Local variables, for example, are not scoped the way you think they are, and you are stuck with a "scratchpad" hack that Hugo put in [2]. To see this in action, here is code I had to write to make a shortcode for responsive images [3]. The entire process involved starting with a JSON file containing the shared configuration, having Grunt read this config to generate the images, and then using the code in [3] to also read from that file and find where the images would be. This is all without syntax highlighting or any useful debugging tools.

There are also just some times you really need HTML in your Markdown, and it doesn't make sense to use a shortcode. For example, a web page that contains very specific formatting that cannot be expressed in Markdown, but is also specific enough to that page to not be separated from the page's content.

All in all, we switched to Hugo for a reason: it had many features that Jekyll was missing at the time (although many it has since added). We wanted to express our website in a well-structured format that also allowed Markdown so not-especially-tech-savvy people could edit content. In the end, we got it working (here's the site, a good example of how a Hugo site can come out pretty great IMO [4]), but it caused a whole lot of pain and misery for me.

[0] https://jekyllrb.com/docs/plugins/ [1] https://gohugo.io/extras/shortcodes/ [2] https://discuss.gohugo.io/t/counter-variables-and-template-s... [3] http://pastebin.com/ZjiWpDHc [4] https://www.castlepointanime.com/

I have also done websites in Hugo; the inflexibility of golang's template processor was extremely limiting to the point that I would never use Hugo again.

I've been using html within my markdown files and hugo without issue. Admittedly, I'm only inserting simple html like h2 elements, or simple links to other sites...but its still html in a markdown file, and hugo does not mind, and in fact processes it all just fine.

I came over from lektor to hugo. As much as I liked lektor's UI (via local website), hugo's binary is far better for me since I'm constantly jumping to different machines (windows, linux, OS X), and didn't want the hassle of set up on each.

That being said, the one thing that is annoying with hugo - and I DID see this with lektor as well though not as annoying as hugo - was wiring up your first template. Ugh, configuring templates - or perhaps more specifically variables - is a big time sink. Other than that, hugo is my generator of choice.

Seconding this -- I use HTML inside hugo all the time. The problem hugo has is that you cannot include _partials_ in your markdown, like you can with Jekyll.

And as parent5446 said, the shortcodes don't give you enough information in some cases.

I also think that people who aren't very technical will have a hard time getting started with the Go templating language, whereas Jekyll is dead obvious (super loose scoping, it looks like any other scripting language, etc.)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact