Hugo 0.28

Tags: #<Tag:0x00007f21b16f04f8> #<Tag:0x00007f21b16f0250> #<Tag:0x00007f21b16f00c0> #<Tag:0x00007f21b16ffe58> #<Tag:0x00007f21b16ffa98>


Hugo 0.28 brings “high-speed syntax highlighting” to the party, via Chroma, “a general purpose syntax highlighter in pure Go” and “based heavily on Pygments”.

Using the now default Chroma highlighter is covered in the updated syntax highlighing documentation. Notably, there are config options for emulating particular Pygments setups.

Both notes are interesting, so quoting them verbatim:

  • Hugo now uses Chroma as new default syntax highlighter. This should in most cases work out-of-the box or with very little adjustments. But if you want to continue to use Pygments, set pygmentsUseClassic=true in your site config.
  • We now add a set of “no cache” headers to the responses for hugo server, which makes the most sense in most development scenarios. Run with hugo server --noHTTPCache=false to get the old behaviour.

Note: there was a performance issue with noHTTPCache, and excluding those headers is the default in 0.29, once again.


This is timely, since I haven’t been able to get syntax highlighting working as I wanted with Pygments, and had started looking at the Prism highlighting library. It is very small! But it is still JavaScript, and if I can get by without it, that is an advantage.

My one concern is the accessibility of code blocks saturated with spans and classes. One reason a JavaScript solution kinda makes sense here is because syntax highlighting is inherently a visual aid, and alternate parsing of a document outside a JavaScript-enabled browser still renders the code as readable and even copypastable (totally a word).

But what happens if the HTML is taken and rendered elsewhere with a bunch of crufty elements? Does that throw a wrench into the works?

Bonus: I fixed a typo in the blog post! But I had to sign a CLA. Meh.

This is a companion discussion topic for the original entry at