
Hugo: A fast and modern static website engine - lnalx
https://gohugo.io/
======
sfifs
The main reason I like Hugo is almost all other engines require me to install
an entire Ruby or JavaScript ecosystem of packages on machine just to be able
to preview my blog post. I don't want to manage the dependency hell when I
don't have to.

~~~
edem
I have never succeeded at installing any Ruby software in one go.

~~~
jajern
I've found that using RVM, much like using virtualenv in python, has helped me
with Ruby issues. It doesn't work exactly like virtualenv but it's pretty
close.

~~~
Funnnny
And then again, it's hard to install a virtualenv successfully the first time.

------
eberkund
Why should I switch to this from Jekyll. There are dozens of site generators
and when I go to their websites they all hash over the same set of features.
Can anyone has used both or any other site generators please let me know what
you found the differences to be?

~~~
andmarios
My main reason, as funny as it may sound, is that it has one static binary.

I do use Jekyll, but given that a site will live for a few years at least,
babysitting a ruby app isn't something I look forward to. Maybe my server has
a different ruby version from my desktop, maybe some ruby gems are installed
by my distribution and some others I have to install manually via gem leading
to an inconsistent system state, every now and then something breaks, some
functionality is provided by a gem I have to install manually and oops, I
forgot to ssh to my server and install it there too. Oh, some gems can't be
build because my server is hardened. Maybe jekyll got a new version and this
leads to new ruby adventures.

Hugo has some other niceties too, like a built-in server with live reload and
some clever link translating while testing on localhost.

~~~
dguo
I've been using the official Docker image for Jekyll
([https://hub.docker.com/r/jekyll/jekyll/](https://hub.docker.com/r/jekyll/jekyll/)),
which makes it fairly easy to avoid this particular problem. Assuming you're
willing/able to have a dependency on Docker.

~~~
andmarios
I am all for docker, we use it on production and I maintain a couple docker
github repos.

But docker also has its own complexities. A user that can run docker, is
almost as good as a user with sudo rights. Would you give your CI system root
access on your server? There are of course workarounds, like permit the CI
system to run only the jekyll image by adjusting the sudoers file but, at some
point you have to think about the scope of configuration needed for deploying
your site.

Also docker on hardened servers can be challenging, for example I had to
disable most of grsecurity's chroot protections to have docker run.

------
justajot
I've built two client sites with Hugo recently with great success:
[https://www.halorestorationservices.com/](https://www.halorestorationservices.com/)
and [http://www.laviagelaw.com/](http://www.laviagelaw.com/). Both are fairly
extensive in their use of templates and Hugo's features.

That said, I typically grab from site templates and don't do a lot of css/js
manipulation myself. Though, if I did, I'd just set-up Grunt or Gulp to handle
automatic regeneration of the final asset files.

For those asking why should you switch? Well, exactly, why should you? If you
are happy with your current toolset and are productive using it, isn't it all
about the final product anyway? Who cares what you use. But if you aren't
happy with your toolset, or are just keeping an eye out for something that
might be better ...

Hugo is known most for its speed. If you have a site with many, many pages
that needs to be built quickly, strongly consider Hugo. It really is super
fast. I'm actually considering building out a very large sample site with
various engines to demonstrate just how fast it is. I'll try to find this post
on Hacker News again and post if I ever get around to it.

Layout of content is extremely nice in Hugo. Basically, you just organize
everything in directories how you want it to be rendered in the end. This can
be overridden if necessary.

Documentation is also really nice. I'm actually about to build another client
site and considered using Jekyll (you know, just to see), but found the
documentation lacking compared to Hugo. It also seems to needlessly complicate
things, but that's probably just personal opinion based on prior experience
with Hugo.

There are a few downsides obviously. You get what you get, unless you want to
add functionality and recompile. But now you have to maintain your own
version.

As parent5446 mentioned, variables can be a bit confusing. They are not as
idiot proof as I'd like them to be.

~~~
Rapzid
Oh man, I just have to comment. These sites are blazing fast. This is to be
expected with static sites, but.. You just don't see them like this much(WP
FTL). Props!

~~~
kensai
Noticed the same thing (visiting from Europe). Wow! :)

------
unsignedint
I love Hugo! I have been hosting
[https://hidekisaito.com/](https://hidekisaito.com/) and its .onion
counterpart [http://hideki24bd6yof6s.onion/](http://hideki24bd6yof6s.onion/)
using Hugo, it's very easy way to get the page up and running. I use Visual
Studio Code to write the contents in markdown, and I got task runner that
configured to run Hugo and then rsync them to the servers.

------
bobfunk
For those wondering what to do with an asset pipeline, check out Victor Hugo
([https://github.com/netlify/victor-hugo](https://github.com/netlify/victor-
hugo)), a boilerplate for using gulp and webpack too manage the asset pipeline
around a hugo based project.

------
michalskop
Is using Hugo suitable even for non-tech people? I have worked with several
systems during last years (Wordpress, Drupal, custom apps, several wikis), but
I am still not happy with them, because of missing combination "easy to
maintain" and "easy to use by non-tech people (when installed)". In my
experience, non-tech people can use markdown (if properly motivated) at most
and can log in into a system, but that is. Is Hugo going to help here?

~~~
bjornerik
There are some hurdles yet to be had for the non-tech person. But I would
claim that when he/she gets the split panel up and running with the markdown
editor on the left and the live-reloading browser on the right, it is no way
going back to whatever Wordpress feeds you.

There are initiatives writing some nice clients on top of static site
generators such as Hugo and Jekyll, but in my head you then lose out some of
the most valuable features of Hugo, speed and simplicity.

~~~
exolymph
I don't think most genuinely non-technical people would prefer Markdown over
real WYSIWYG.

------
sandstrom
There is a growing trend of static websites.

My favorite tool for static websites is Middleman
([https://middlemanapp.com/](https://middlemanapp.com/)), but competition is
always good.

------
qwertyuiop924
But why this over another site generator? Metalsmith has total flexability,
Lektor has a web UI for those who dislike writing in plain text, Jekyll has
simplicity... Hugo doesn't really seem to have any advantages.

~~~
ausjke
there are at least 10+ good static site engines, why is Hugo better? I tried
many of them and Hugo definitely has nothing to stand out in my experience.

~~~
spf13
Disclaimer: I am the creator of Hugo. Trying to provide an impartial
perspective here for the readers.

Everyone has different needs and tastes so no tool works for everyone. Here's
how I see Hugo's strengths and weaknesses. I'd love to know what other people
see are Hugo's strengths and weaknesses.

Hugo's key differentiators: 1\. Ease of install 2\. Speed (critical for large
sites) 3\. Integrated live-reload while editing in near realtime 4\.
Multilingual capabilities 5\. Flexible 6\. Very strong community 7\. Very good
& comprehensive documentation (but not perfect...yet)

Hugo struggles with: 1\. Not integrated with Github like Jekyll (though
webhooks solve this to a large degree) 2\. No plugin support 3\. Media & Asset
processing not tightly integrated

There are many solutions that work around Hugo's limitations, some which are
quite elegant, but at the end of the day they are workarounds and require
external tooling.

We would love to address these weaknesses in upcoming releases as best we can.
If you are interested in helping we would love to have help.

~~~
alxndr
Just wanna say thanks for having RSS support!

------
smizell
I think one the biggest draws of something like Hugo would be that it's
amazingly fast. You can check out the video [0] here that shows a benchmark.
It generates 5,000 pages in around 6-7.

Another is that it's a single file to deal with. This may be different when
you get into making your own themes, but to get going you just need to
download the single file for your platform.

[0]:
[https://gohugo.io/overview/introduction/](https://gohugo.io/overview/introduction/)

~~~
glandium
The video showing two benchmarks, one on a SSD and one on a HD, is kind of
pointless and possibly misleading. The files are already in memory cache, and
the disk is not being read from. There is no way 5000 files can be loaded off
a HD in less than 6 seconds, especially on NTFS.

That doesn't make the benchmark totally uninteresting, though, because dealing
with 5000 posts in 5 to 7s is still good, and would be what you'd get from
several rendering iterations, which you'd get for subsequent edits of your
text, or tweaks of your templates.

The point I'm trying to make is that he should not care about showing more
than one measurement.

------
nickthemagicman
I tried out, Jekyll, Hugo and neither one met my needs.

I found middleman to be the most powerful static site generator.

~~~
kornish
Out of interest, which needs of yours weren't met by Jekyll and Hugo?

~~~
nickthemagicman
For a bizzare reason you cant combine pagination and categories in Jekyll?

I had to try to hack add ons like jekll paginate.

Hugo actually had all the features I wanted but It was something to do with
the locations of templates for custom collections were in a very opinionated
yet weird place and the docs werent super clear about how it worked? And
theres literally only a handful of tutorials.

Theres a lot of good about Hugo though and Im not denigrating it all.

Middleman was just perfect on every level. Elegant, customizable, feature
rich, with great docs.

Its also Ruby so its like an evolved Jekyll pokemon.

But then again all this is just my opinion. :)

------
joneholland
I tried Hugo on a quick prototype for a API documentation site, but quickly
ran into limitations in the go template engine and how Hugo handles variables.

It's great for a simple static site, but without a way to extend the template
engine easily, there was no way to do what we wanted (which was to style a
yaml file of service metadata into a swagger like UI).

~~~
mlent
I agree -- I have two blogs in Hugo, which I really liked, but have built the
biggest site in Jekyll and the Liquid templating language is super powerful.
However, Jekyll quickly got slow owing to the same powerful templating
language. Always tradeoffs :)

------
shapeshed
I switched from Jekyll -> own rolled Node.js generator -> Hugo.

For me it is better because of simplicity and speed. I use it to power a 400
page blog ([https://shapeshed.com/](https://shapeshed.com/)) with this source
code
([https://github.com/shapeshed/shapeshed.com](https://github.com/shapeshed/shapeshed.com)).

I used Jekyll in a small organisation and it meant everyone needed a working
Ruby environment This caused much pain across platforms. Hugo ships a single
binary for multiple platforms so setup is far simpler. It is also amazingly
fast and there have been major performance improvements in 0.17 too
([https://gohugo.io/meta/release-notes/](https://gohugo.io/meta/release-
notes/)).

I love it!

------
parent5446
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/](https://jekyllrb.com/docs/plugins/)
[1]
[https://gohugo.io/extras/shortcodes/](https://gohugo.io/extras/shortcodes/)
[2] [https://discuss.gohugo.io/t/counter-variables-and-
template-s...](https://discuss.gohugo.io/t/counter-variables-and-template-
scope/382) [3] [http://pastebin.com/ZjiWpDHc](http://pastebin.com/ZjiWpDHc)
[4] [https://www.castlepointanime.com/](https://www.castlepointanime.com/)

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

~~~
mlent
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.)

------
devin
I doubt this opinion is fashionable, but I prefer simple. HTML or bust.

~~~
blacksmith_tb
But aren't static site generators essentially agreeing with you? Obviously
they are easier to scale up, too - manual find-n-replace across a site with
hundreds of pages is a lot more risky than letting automation take care of the
details.

------
kaushalmodi
I started developing my blog using Octropress (Jekyll derivative) many years
back. I painfully installed it the first time (Ruby dependencies). I tried
upgrading to Octopress 2.0 probably 2 years back, but I was never successfully
able to install all the dependencies on my work machine. More than that, I
never got it working on multiple platforms. I wished to be able to post to my
blog from both home (Windows) and work (RHEL6.6), but that just wasn't
possible.

Hugo was a breath of fresh air:

\- Easy to install (auto-installs all the dependent go packages without a
hitch, and results in a single static binary!)

\- Easy to set up a web page (hardly took 10 minutes)

Having the basic web site building going, I can now tinker as I like with the
layouts, config.toml, etc. Hugo has allowed me to focus more on my web site
content and design than burning time figuring out how to successfully install
(and keep upgraded) the web site building. (All I need to do to update hugo to
the latest and greatest is: "go get -u -v github.com/spf13/hugo").

------
chewxy
I was surprised that I had a already-visited link on HN. This weekend I was
trying to migrate my wordpress blog to Hugo... to no avail. The plugins
mentioned all killed my Wordpress, so now I'm stuck transcribing my posts one
by one by hand. Anyone knows of a good exporter for WP that keeps the
footnotes/ref and doesn't kill WP?

~~~
girvo
Perhaps give WP-CLI a try? [0]

[0] [https://wp-cli.org/commands/export/](https://wp-cli.org/commands/export/)

------
smagch
Docker documentation recently moved away from Hugo in favor of Jekyll.

[https://blog.docker.com/2016/09/announcing-new-docs-repo-
git...](https://blog.docker.com/2016/09/announcing-new-docs-repo-github/)

In the blog article above, they mentioned a problem they faced.

> The docs were built around Hugo, which is not natively supported by GitHub,
> and took minutes to build, and even longer for us to deploy.

I've been using Middleman for static site for a couple of years. I'm thinking
about moving to Hugo because I read HN comments Hugo is much faster than other
alternatives. But reading the official Docker blog, I'm thinking twice.

Could anyone tell me the reason why Docker blog took too much time to build
with Hugo that is supposed to build really fast?

~~~
rplnt
> Docker documentation recently moved

> the reason why Docker blog took too much time to build

Not the blog, but documentation. And it takes so much time because it's just
so huge. Just by itself it would be pretty big, but consider that they
maintain a clone for each release version. You end up with lots of documents
very fast.

What I'm not sure about is why it would have to be completely rebuilt every
time since the build results would have to be committed. Maybe they had two
repositories? Or Hugo can't do "incremental" builds well?

~~~
spf13
Disclaimer. I am the author of Hugo and former exec at Docker. I don't speak
for Docker and I've been gone for over a year so the following is at best a
guess.

From my reading of their blog post I see that their primary motivation for the
change was first to consolidate all of their documentation into a single repo,
instead of spread across all of their various projects. As they have grown as
an organization and now have a large number of projects this approach has a
lot of strengths and makes a lot of sense. Any SSG could work in this new
formation, but the change gave them an opportunity to make a change.
Additionally Github provides a lot of Jekyll features out of the box that help
with managing these documentation sites.

I believe it is not a question of performance between Hugo and Jekyll, but a
question of Docker's specific workflow. As Github already runs Jekyll server
side all the contributors need to do is upload the source file and then Github
does the rest. In contrast, Hugo based docs would have to be built locally and
then uploaded as completed html. There are easy ways to set up services
through github hooks that do the exact same thing as Jekyll already does but
that requires additional setting up.

Since Github is doing all the work it is easier on the contributors since all
they need to do is `git push`. This also enables people to edit right in the
github edit screen and not bother with setting up anything client side. The
total time to process the site is likely much longer on Jekyll but the time
that their contributors spend is much less as they aren't building the site
locally.

------
pmlnr
I tried out dozens of generators; for plain, simple, mostly text blogs, Hugo
is fine. And Pelican, and Jekyll, and nearly all.

Hugo falls short when it comes to custom needs, like EXIF handling, or
intermediate image downsizing for responsive images, because adding features
to Hugo is painful.

~~~
senorjazz
If you want custom features the only option I found is Nikola : get Nikola.com

The plugin system let's you do nearly anything you can think of,and if not the
devs are will consider updates to make it possible

~~~
guitarbill
Obviously not true; a quick search shows the two options the op mentioned,
Jekyll [0] and Pelican [1] have plugins.

I'm familiar with Pelican. Apart from writing plugins (with excellent signals
to hook into), you can replace the main class with a custom class and get
basically any behaviour you want.

[0] [https://jekyllrb.com/docs/plugins/](https://jekyllrb.com/docs/plugins/)
[1]
[http://docs.getpelican.com/en/3.6.3/plugins.html](http://docs.getpelican.com/en/3.6.3/plugins.html)

------
bjornerik
Steve Francia has written a nice blog article about the recent Hugo 0.17
release: [http://spf13.com/post/hugo-goes-global/](http://spf13.com/post/hugo-
goes-global/)

~~~
themodelplumber
Great update and a nice blog. I wonder if he knows about the distasteful ads
that are shown by Disqus, right underneath his own writing.

~~~
spf13
I didn't. I'm shocked how awful these ads are. I've turned it off completely.

------
sohkamyung
The Taxonomy section of Hugo sounds interesting [1]. I've been putting up my
personal comments and reviews of stories in book anthologies and magazines via
Goodreads. I also put up reviews of individual books on Goodreads. I would
love to be able to organise what I've written in a static website via
categories like story title, author, magazine/anthology appearances, etc. and
this looks like the way to do it.

\- [1]
[https://gohugo.io/taxonomies/overview/](https://gohugo.io/taxonomies/overview/)

------
brusch64
Is this a viable alternative to Hyde (the python static site generator) ?

I was using this instead of Jekyll for a hardly updated website and I can't
get it running on Arch linux (without putting too much effort into it). The
whole system looks pretty dated and dead too (I think the upstream URL doesn't
even work any more).

I would be really happy to get a "set and forget" solution, so I can update
the site 3 times in a year and don't have to worry about the system.

Is Hugo stable enough for something like that ? Is the Jekyll Docker image the
better solution for this ?

~~~
icebraining
I'm sure Hugo is fine, but if you want something in Python, try Pelican. And
use a virtualenv, to avoid mixing up the system libraries with it. In my
experience, it'll essentially work forever.

~~~
brusch64
I don't really care if it is Python or any other language. Hyde looked okay
when I've started with it (altough the lack of documentation should've been a
warning sign).

------
nzjrs
Is it modern because it's written in Go, or am I missing something?

~~~
coldtea
It is modern because it's not based on some 20 year old unmaintained Perl CGI
script.

~~~
shincert
Which static site generator is based on a 20 year old unmaintained Perl CGI
script?

~~~
devonkim
I used to use Blosxom for a while and found the Jekyll workflow somewhat
comparable.

------
madmax108
I use Hugo for a Deep learning blog I just started writing
([http://navinpai.github.io/ga](http://navinpai.github.io/ga)) as a self
reference.

The main reasons I like hugo:

\- The single binary (which others have mentioned)

\- The theme support (Somehow, Hugo themes are well designed as opposed to
Pelican themes which seem more thrown together)

\- The folder structuring is very intuitive

All in all would definitely recommend

~~~
BOOSTERHIDROGEN
would you mind create a blog post how to create your blog using this tools.

------
jonathonf
Some previous discussion:

* [https://news.ycombinator.com/item?id=10646508](https://news.ycombinator.com/item?id=10646508)

* [https://news.ycombinator.com/item?id=10627585](https://news.ycombinator.com/item?id=10627585)

Strangely I can't find any posted story for the 0.16 release...

------
abhv
I am a hugo user, but I noticed that it has been slower and slower. I ran a
--stepAnalysis, and it shows that the most expensive step is

Started building sites ... Go initialization: 5.722103073s (5.722526117s) 2.66
MB 22083 Allocs

The rest of the steps take 115ms. What is happening in go init, and why does
it take so long?

~~~
spf13
This is surprising and counter to what most others are experiencing.

Many of the performance optimizations have tradeoffs and while they increase
performance for the majority of cases, some cases will experience slight
degradation.

This is also a surprisingly long time for initialization. My site with a few
hundred pages on a rather old mac (with an SSD) has

Go initialization: 48.00164ms (48.842363ms) 2.14 MB 18299 Allocs

Do you have your site source available publicly so we can do more testing and
benchmarking with it? We'd love to understand the places where it's not
improving so we can address them further.

------
rhabarba
The only thing that is said to make Hugo better than other static site
generators is that it compiles fast. This is probably because of Go. Now Go is
so fast because it uses ALGOL's compiling methods...

I wonder how fast Hugo would be if it was written in Pascal instead.

~~~
bjornerik
One could also argue that developers also has some impact on speed in an app
like Hugo. The measured speed increase from Hugo 0.16 was 40/60 Go vs
Developer.

------
wtbob
Weird that their header over 'Run Anywhere' reads 'S Q R.' Is it perhaps a
mis-spelt allusion to the senate and people of Rome?

~~~
carterehsmith
Wasn't that more like 'SPQR'?

[https://en.wikipedia.org/wiki/SPQR](https://en.wikipedia.org/wiki/SPQR)

~~~
wtbob
Yes, that's why I wrote 'mis-spelt.' I was making a point about their use of
JavaScript to load fonts to display glyphs, which of course fails miserably if
one has JavaScript disabled (as anyone who cares about privacy and security
does).

------
jsherman76
so after going to your landing page, I'm still unsure of what I get from Hugo?
I use bootstrap to build my websites. How does Hugo work exactly?

~~~
bborud
Let me sum it up for you: it is yet website generator that allows you to spend
an entire weekend making something that almost works while reading reams of
boring documentation.

The next weekend you will already have forgotten how to work it and you think
"fuck it" and either install Jekyll (which is also a piece of shit, but it is
a piece of shit that has a bigger community) or you think "screw this" and
sign up for some website generation service your slightly odd uncle uses.

Wake me up when someone makes a website generator for people who really aren't
interested in website generators.

~~~
mattkevan
That would be me. I found Hugo and Jekyll because I wanted a simple but
powerful way to build websites.

After using Drupal and Wordpress for years they're a total breath of fresh
air.

I can put together a site in a fraction of the time it would normally take,
host it for free, and through services like Snipcart, Typeform and
Forestry.io, add some surprisingly sophisticated functionality.

For what they do, Hugo and Jekyll are excellent.

~~~
bborud
That mostly says something about Drupal and Wordpress.

