This statement caught my attention in the article:

> It is optimized for speed (Hugo sites can be built in milliseconds)

Is that true, or does it just happen to be fast? It seems to me that the performance of a static site generation is irrelevant, and thus time spent on this is really wasted effort.

I don't care if it takes several minutes to build.. it'll happen on the CI server in the background, and so long as the actual deployment is atomic, it makes no difference.

A site that has time-sensitive content or update requirements of more than hundreds of times per day seems to be a poor candidate for use with a static site generator.

I've just migrated to Hugo, and agree with the comments that it really does matter. Between the near-instant compilation and the live reload, the Hugo development server can update a local copy of your site in the browser faster than you can switch tabs. In effect, you get genuinely instant preview anywhere, out of the box.

In every respect, Hugo is a really good site generator (not just a static blog engine), but this is the feature that makes the competition near-irrelevant to me.

It tends to matter a lot in two cases:

1. During development. Having instant builds running whenever you save is great for the development experience

2. For really large sites. Being able to build many thousand pages in about a minute instead of 20 minutes or way more is a huge difference for the authoring experience.

Number two is why I use it. My site has about 2300 pages and regenerating the whole thing when I tweak one part or another of the basic template or change themes is less than two seconds. Extraordinarily fast and encourages experimentation at least for me. Maybe folks with better front end skills wouldn't care but it's great in my experience

Yea gonna agree with u:bobfunk here that it's really about local development where it matters. And yes it is very fast in my experience, although I don't push it as much as others do.

It's also amazing to just have a single binary (or go get -u command) to get going unlike jekyll or the gems to run github's jekyll environment locally. I can't tell you how many times I'd just not blog in a while and need to setup this whole crazy setup for local jekyll and I'd just never write the post because of it. Hugo makes things simple, fast, and extensible.

edit: also I usually do the build locally and commit that to a specific repo which has the final rendered version for easy deployment to github and other places. I've made a `Makefile` just to do this easily as `make publish` to get any changes I have build, commited to the rendered repo, and commited to the source repo.

> It seems to me that the performance of a static site generation is irrelevant, and thus time spent on this is really wasted effort.

Another consideration is pages which take a long time to render. When I'm writing about code (which is a lot!) I use a literate programming style, so that code snippets on a page can be executed and have their output embedded in the HTML. This ensures that the code I'm discussing actually works as claimed, and keeps everything self-contained; but it can make rendering arbitrarily slow!

At the moment, the longest wait is a few minutes for the graphs on http://chriswarbo.net/blog/2014-07-23-fib.html and the images on http://chriswarbo.net/projects/procedural/cantor.html

As long as the build system is incremental (I use GNU Make) the cost only has to be paid when changing those pages (either their content, or a template), so it doesn't slow down the edit/build cycle for other pages.

Do you have an example that shows this? I'm interested in bringing something like that into my own site.

I wrote it up at http://chriswarbo.net/projects/activecode

The process I use is very simple: shell commands are written as attributes of code blocks, and during rendering the content of the code blocks will be piped into those commands. Hence we can run a bash script by giving its code block a pipe="bash" attribute, python scripts by using pipe="python", haskell by using pipe="runhaskell", and so on for anything that can be called from a shell.

This is all powered by a couple of scripts based on Pandoc.

If you want to see some examples, click the "View Source" links at the bottom of my site. The pages I linked to above are quite complex, but some simpler examples are:

- The blog post listing comes from a `find` command http://chriswarbo.net/blog.html

- Images can be embedded using base64 URIs http://chriswarbo.net/blog/2015-06-06-more_git.html

- Code snippets can be checked, and we can even include real error messages http://chriswarbo.net/blog/2015-11-12-calculating_arity.html

> It is optimized for speed (Hugo sites can be built in milliseconds)

I suspect it's based on a minimal set of test cases, not a full site. With hundreds of pages mine takes anything from 30 seconds to a couple of minutes to build.

As with everything, this is a huge oversimplification (i.e. Go = faster than scripting languages). I'm dubious if the algorithmic part of static site generators dominates. Would have though it's I/O bounded to some degree, in which case Go isn't going to be faster than anything else.

Besides, caching solves this issue better, unless you change the underlying templates.

Are you using the syntax highlighting (i.e. Pygments) feature? It significantly raises the generation time.

I also just started using and am really liking it so far. Relatively easy to set up, nice modern themes, and as others have said, the live reload and fast generation are awesome. My first post[0] explains how I use it with GitHub Pages to track commits and host.

[0] http://www.getup8.com/post/blogging-in-hugo/