
Hugo – Golang static site editor - bluemenot
http://www.gohugo.io/
======
jmduke
I use Hugo for one of my side projects' static sites, and actually just today
migrated from using HTML templates to Ace. (I also use it for my blog.)

My pros and cons of Hugo:

\+ It's fast.

\+ Like, really, really fast. I'm looking at <1s builds for a couple thousand
pages which took around 5-8s in Pelican.

\+ A lot of really nice out-of-the-box stuff like markdownifying arbitrary
strings, rss and sitemaps, etc.

\+ Extensible front matter system. (I abuse it to stuff an arbitrary JSON
object into each page.)

\+ Did I mention how fast it was?

\- Debugging is hell. Error messages are unintelligible and generally distract
from whatever the actual issue is.

\- The structure of a theme is sort of unintuitive, but that may be personal
preference.

\- Lack of support for more user-friendly templating languages like Jinja2
(this is likely due to speed, but I'd still like the options.)

~~~
ajslater
pango (jinja for go) exists, but no one (including me) has stepped up yet to
write a plugin for it.

------
hunvreus
I started looking into Hugo as a faster alternative to Jekyll. Two reasons why
you'd disregard the fact that Hugo doesn't have the same support as Jekyll on
GitHub pages:

1\. You're dealing with thousands or more pages. Jekyll can be slow as heck
passed a few hundreds of posts. Benchmarks [1] show that Hugo is way

2\. You want to avoid dealing with Ruby. Honestly, every single time I have to
install a Ruby app I end up wasting 30 minutes on nonsense (wrong version,
dependency hell, ...).

There are many things you can try to improve the speed of your Jekyll site
(avoid loops, use Javascript to load some elements/features, leverage some
configuration tricks [2]), but Hugo is just flat out much faster and much
easier to deploy.

[1]: [http://fredrikloch.me/post/2014-08-12-Jekyll-and-its-
alterna...](http://fredrikloch.me/post/2014-08-12-Jekyll-and-its-alternatives-
from-a-site-generation-point-of-view/) [2]:
[http://scottpatten.ca/2011/11/speeding-up-jekyll-
generation....](http://scottpatten.ca/2011/11/speeding-up-jekyll-
generation.html)

~~~
tvon
> _You want to avoid dealing with Ruby, (...)_

It annoys me when using a tool require a functional development environment
for the ecosystem it is based upon. E.g., ruby-based tools install via 'gem'
and node-based tools install via 'npm', both of which are potentially huge
hassles.

A nice aspect of go-based tools is that you can always just download a binary.

~~~
SomeCallMeTim
It is awesome to be able to build a binary with go.

But despite the recent Node major version upgrades, I've had almost no
problems with npm, while I always seem to have issues with Ruby/gem installs.

Binaries with no dependencies still win for convenience, but even Go has an
ecosystem of libraries to deal with if you need to rebuild something. So I see
the three on a spectrum: Go is always awesome, NodeJS usually works (and often
has a package that supports functionality that Go lacks), and Ruby
consistently makes me sad.

NodeJS also has a larger pool of experienced developers, which isn't
everything, but it _can_ be important, depending on whether the project is
something that I will want to eventually offload.

~~~
TheDong
> Go is always awesome

If you need to build a version of master, or the project doesn't provide a
static binary, or you don't wish to trust some random binary on the internet,
or you wish to package a Go binary, it suddenly becomes terrible.

1\. Build a version of master -- Go does not have a way to version or lock
dependencies, so it's possible master will only build on the developers
machine. The state of the art solution for that is vendoring, but each
vendoring tool behaves slightly different, and even that results in some hell.
It's not fun.

2\. No static binary -- See 1, except now you're supposed to use 'go get'
which is one of the most error-prone pieces of shit I've ever seen. It won't
work with vendoring, so have fun.

3\. Don't trust a random binary on the internet -- See 1 or 4

4\. Package for a distro -- Good luck packaging go well. The informal ad-hoc
dependency mess ensures that properly packaging go is almost impossible. The
vendoring tools means you'll have hell modeling dependencies so you can react
to security issues. Basically, your life will suck.

Ruby and NodeJS have none of those problems. To build a version of master, you
have a gemfile / package.json that, if it follows specifications, will
correctly tell you _everything_ , down to the version, that should be
installed.

Distros have tons of tools for packaging those languages and modeling them
well. It works and is usually easy.

There's a single distribution method (npm / rubygems) so you don't have to
check if there's a site with a curl | bash script, or a static binary
download, or a github release page, or some other strange situation.

> NodeJS also has a larger pool of experienced developers

Citation needed. I have no qualm with the "larger pool" bit which very well
could be true, but "experienced" and "NodeJS" don't go together so often in my
book

~~~
SomeCallMeTim
>To build a version of master, you have a gemfile / package.json that, if it
follows specifications, will correctly tell you everything, down to the
version, that should be installed.

You _can_ set specific versions, but the default behavior is to do >= or ~
versions, at least in Node. But you could potentially go in and change the
references to =version# to get a version closer to the one the developer built
-- but even then there's no guarantee that the latest build hasn't had a more
recent download of the packages, with newer versions than those specified in
package.json.

But I didn't know this about go package importing. I'm a bit disappointed that
they didn't at least make it possible to import @ a particular hash.

You _could_ look at the last check-in and pull versions of each of the
dependent repos as of that date, if the latest builds don't work.

>"experienced" and "NodeJS" don't go together so often in my book

Touche.

But I've encountered similar issues with Ruby, TBH (allegedly senior
developers who turn out to be slow and not as experienced as I had hoped), and
it happens that the JavaScript developers I have around me seem stronger than
the Ruby developers. But more and more developers are training every year; I
read one article that alleged that junior developers outnumber senior by a
factor of something like 18-1 at this point. So I'm statistically likely to be
surrounded by an insulating layer of junior developers no matter the language
I choose. :)

~~~
TheDong
The default behaviour is a safe semver selector.

If I type "npm install --save foo", it gives me "^1.2.3" which says
"everything compatible with the current version".

If you don't follow semver specification and make incompatible changes, well,
:(

You also have the wonderful npm shrinkwrap command
([https://docs.npmjs.com/cli/shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap))
which locks you down similar to a Gemfile.lock, but inline with how the npm
world works.

Thanks for tooting your horn about being senior while also being factually
incorrect about the default behavior of node and not knowing you can use
shrinkwrap to leave the loose version specifications but also commit what they
actually resolved to on your machine.

------
liquidmetal
I use hugo on my personal blog at the moment.
[http://utkarshsinha.com/](http://utkarshsinha.com/)

A few things I've found interesting are:

\- Getting the layout just right takes a bit of tinkering (I mean the layout,
theme and include file locations - not the CSS).

\- The `hugo` executable is just perfect. hugo server --watch is all you need
(plus it's super fast!)

\- Also, I'm not a Ruby person. I don't need a whole Ruby ecosystem working on
my machine just to parse some markdown.

~~~
kxyvr
I'll second these comments about Hugo. I use it with my business website
([http://www.optimojoe.com/](http://www.optimojoe.com/)) and have been
extremely happy. As a couple more comments:

\- Grab the repo
[https://github.com/spf13/hugoThemes](https://github.com/spf13/hugoThemes) and
flip through the themes. Personally, I don't keep the repository in my Hugo
project, but just have a soft link to the base directory. Then, the command
`hugo server --theme=MyThemeHere`, let's me instantly see what my website
looks like under a new theme.

\- The ruby gem s3_website
([https://github.com/laurilehmijoki/s3_website](https://github.com/laurilehmijoki/s3_website))
lets me update my Amazon hosted website instantly. Basically, I just run `rm
-rf ./public && hugo && s3_website push` after adding a new page and I'm done.

\- In any case, like liquidmetal, I'm not a Ruby person, but I was able to
easily modify the themes into something that worked well for me. I started
using Hugo after running through the other popular static site generators and
found Hugo the easiest to get up and running and maintain.

~~~
lukebennett
Useful insight, thanks. Heads up your business website has an invalid link -
"Products" is missing a slash and currently points to
[http://www.optimojoe.comproducts](http://www.optimojoe.comproducts)

~~~
kxyvr
Thanks for tip on the links! I screwed up my front page template, but it
should be fixed and percolating through CloudFront. Thanks again!

------
hendry
I found Hugo too complex, so I wrote my own static site generator in Golang. I
also didn't like that I couldn't get commonnmark to run simultaneously, so I
use `make` & yes it's fast and easy on my brain.
[https://github.com/kaihendry/natalian](https://github.com/kaihendry/natalian)

------
bobfunk
Hugo is awesome, especially because of the speed of builds. We use it with
netlify for [https://www.staticwebtech.com](https://www.staticwebtech.com) and
it generally takes around 5 seconds from we push to git and until a new
version of the site is live.

Here's a quick guide on settings up automated deploys with hugo and netlify:
[https://www.netlify.com/blog/2015/10/06/a-step-by-step-
guide...](https://www.netlify.com/blog/2015/10/06/a-step-by-step-guide-hugo-
on-netlify)

------
desireco42
I just tried to make a Hugo website and it was easy. I don't think it is super
important, but you can't not notice how fast it is.

I am a ruby guy and I really like Middleman, but there are things to like
about Hugo. I like how it can pull data files. What I am not sure and need to
explore, with Middleman I can implement pulling of the data, I am not sure I
could do this with Hugo, but on the other hand, it can pull CSV and JSON from
remote, so that is good. Also, taxonomy looks nice, I can see how all this can
be useful.

Overall I am pleasantly surprised how well it is done. Some syntax definitely
looks weird, but it might be just that I need to adjust to it.

Really happy to discover something new. Excellent work.

------
elmin
If you need a way of deploying a Hugo site, I highly recommend Stout [1].

1\. [http://stout.is](http://stout.is)

~~~
krat0sprakhar
My vote for deploying static sites goes to
[https://surge.sh/](https://surge.sh/). It's wicked simple and CDN backed!

~~~
bobfunk
It's not actually CDN backed unless you consider a single PoP in Digital
Ocean's San Francisco datacenter a CDN...

------
Shad0w59
I briefly reviewed some static site frameworks and found that Hugo was one of
the few that supported complex taxonomies. Anyone had any experience with more
complicated sites?

The movie example is similar to what I am after:
[https://gohugo.io/taxonomies/overview/](https://gohugo.io/taxonomies/overview/)

------
PuffinBlue
Hugo is a great tool with a very responsive dev team and friendly community.

I use it myself for a couple of sites and I hope that the team continues to
get the recognition it deserves for creating such a useful bit of software.

Incidentally, the license has recently changed to the Apache 2.0 license so
hopefully this will encourage even wider adoption/contribution.

------
rjbrock
This is actually what I am using now on my personal blog
([https://brock.io](https://brock.io))

I went with hugo because it is very fast, and I didn't need to install any
dependencies locally or on my server.

I bought a theme from themeforest and converted it to a hugo theme. It was a
great learning experience, but the docs on actually creating a theme were a
bit thin.

------
ngrilly
The title is wrong: Hugo is not a static site _editor_ ; it is a static site
_generator_.

------
ksubedi
I am currently using it for my blog at
[https://kaushalsubedi.com/](https://kaushalsubedi.com/) and as someone who
just switched from WordPress, the difference is night and day. I threw the
site in a CDN and everything loads almost instantly since its all static.

Hugo compiles fast, and the templating system is easy to understand and
modify. Only wish it had support for directly compiling it and pushing the
changed files from last pushed version via SFTP or even FTP.

~~~
jscholes
Just FYI, your navigation menu is an unordered list, but all the links are in
one list item instead of multiple ones.

------
geraldbauer
FYI: Hugo has won the static site builder / generator of the year 2015 award
(in the alternative category) ->
[https://twitter.com/viennahtml/status/669540918714695680](https://twitter.com/viennahtml/status/669540918714695680)
Congrats. PS: In the ruby category the winner is Jekyll and in javascript the
winner is Metalsmith. Cheers.

------
zatkin
That inverted Linux hover icon looks terrible.

------
tasnimreza
People are claiming it is fast but based on what ? faster development, run
time, concurrency, async parallel task handling, based on which parameter you
can say it is fast ? is it noticeable for small scale project ?

------
detaro
Huh, interesting. Doesn't seem to spend any effort on only updating things
that need to be updated, but just tries to be fast enough that it doesn't
matter if it redoes everything? That approach doesn't look so good once it has
to do expensive tasks, like image processing, but for HTML generation it seems
to work.

------
giancarlostoro
I recently started to use Hugo for a not yet done static website I'm working
on, I must say I enjoy it. I haven't deployed the site or anything yet since
I'm merely experimenting. I kept trying static site generator scripts in
Python 2 / Python 3 but they seem to fail for me for one reason or another.

~~~
imron
Yep, I'm basically the same - working on a static site, investigated a bunch
of alternatives, and Hugo came up the clear winner.

------
programminggeek
It's not quite live yet, but I'm working on a static site hosting solution
[http://statichosting.co/](http://statichosting.co/). Zip up your site and
upload it. That's it.

If you're interested in the beta, hit me up on twitter @_brianknapp.

------
gntech
I am using Hugo on my personal site
[http://www.gntech.se](http://www.gntech.se) and i Like it alot! Coming from
Jekyll and Pelican I really appreciate the build speed and the minimal
environment setup that is needed! Highly recommended tool!

------
mhd
Is the speed really that much of a problem? About 90% of all SSG-based blogs
I've seen contain about half a dozen posts, as switching/using a SSG was
basically the reason someone got (back) into blogging. And then abandoned it
six months later.

------
Animats
It looks like it's basically a markdown to HTML translator, with a scheme for
specifying formatting in YAML. It's almost easier to write HTML by hand.

(I still use Dreamweaver 8 for static pages. They render just fine with modern
browsers.)

~~~
jacquesm
It's easier to write HTML by hand if you only have a few pages. But if you
have a few hundred or a few thousand pages a site generator can save you a lot
of time and sometimes your sanity.

~~~
bobfunk
Apart from that, separating content and design can also be a big deal for
working with different kinds of tooling.

You can use hugo to fetch JSON, YAML or CSV data from remote URLs and use
those data as part of the build process. And if you use local data files
instead of HTML you can use a tool like netlify-cms
(github.com/netlify/netlify-cms) to give end users an easy way to work with
that structured data without ever touching text editors or the like...

And as jacquesm said, once you have a more complex site with lots of pages,
you'll want to use partials, reuse content in different places (show a summary
of an article on an index page, full article inside, small blurbs on the
homepage, etc), and once you get there you really don't want to write HTML by
hand...

~~~
mjsweet
Oh wow, I just looked up their doco, and found the csv and rest connectors.
Thank you so much for this. Had I known I may not have built a recent parts
database website with harp.js and a weird mashup of php, bash and even a go
sitemap script. Dumping out csv files from excel, iterate through said csv
files with php and dump ejs files with part (628 in all) then harp compile
followed by an s3 sync for all 633 pages on the site. All scripts referenced
from one bash file. I felt clever! But won't feel clever when I rebuild my Mac
with X number of environments (npm, php, aws sdk, OSG) to build the site. With
Hugo and also stout [1] also mentioned here, the workflow is alot more
predictable, and binaries could be kept in the project for easy portability.

Also worth mentioning is OSG [2], a sitemap generator written in go that I use
in my bash script. It's very fast. This may have some advantages over hugos
built in sitemap generator depending on your site, though I think I would use
hugos in most cases. Might be useful for others using other static generators
that don't support sitemaps and also have other CMS's and carts / forums
installed too.

[1] [http://stout.is](http://stout.is) [2]
[https://github.com/patrickmn/osg](https://github.com/patrickmn/osg)

~~~
bobfunk
You're welcome! And give netlify a try (I'm a founder). For a large site with
hundreds of interlinked pages, S3 has the problem that there's no good way to
do atomic deploys (what they call all-or-nothing consistency for whole deploys
in the stout documentation).

Netlify will make sure you get true atomic deploys where no changes go live
before all changes have been uploaded and handles instant cache invalidation.

We have built-in support for hugo for our integrated continuous deployment
system, and can do builds triggered by webhooks. So for any setup where you're
building based on external files, you can easily trigger rebuilds whenever one
of those datasources gets updates...

