Astute Communications Blog Hero

In our previous article, we covered the options for generating a static version of your WordPress site to deploy separate from your main web server. In this article, we’ll cover one of the hundreds of other options from within the Jamstack, called Hugo.

What is the jamstack?

The “Jam” in Jamstack (formerly stylized as JAMStack) refers to three core technologies –

  • JavaScript, for creating the business logic of your website;
  • APIs, which stands for application programming interfaces, referring to the consumption of third-party services to provide dynamic functionality to your website;
  • Markup, referring to whatever language is used (such as HTML) for creating the markup, or structure, or your website.

These static generator technologies come in all shapes and sizes, including variations in how page routing, page rendering, SEO, and content management are handled. In the next section, we’ll introduce one of our favorite Jamstack options, Hugo. 

Why hugo?

The “go” in Hugo refers to the Go Programming Language, developed by Google. Its purpose in Hugo is to serve as the engine used to compile content files into a fully-developed front-end site. Using Hugo doesn’t require you to know the Go language, but does require it to be installed on your developer’s computer. 

As with other static site options, the hosting for the statically output files can be any number of providers, and is much cheaper than hosting a WordPress site. Hugo, because it compiles to a static website using HTML, CSS, and JavaScript, conveniently handles page routing, page rendering, and SEO the standard way – using metadata within flat files on your host.

Speaking of flat files, this is also how Hugo manages content. By default, all content on a Hugo site is managed using .MD files, which stands for Markdown (which outputs as markup, the distinct topic we mentioned above). Even if you’ve never heard of Markdown, you’ve probably used applications which support a similar syntax. So if you’re comfortable creating a bold or italicized message in Slack, you’ll be able to pick up Markdown very quickly.

In Hugo websites, theme and content are mixed together, and are structured using the following folder structure

  • archetypes – when creating new content, archetype files (one per content type) tell Hugo which options to provide for metadata. For example, the fields relevant to your Blog Posts may not be relevant to your Locations, so they each need separate templates when creating a new instance of each
  • assets – a folder used by Hugo when compiling assets using Hugo Pipes. Only relevant when doing custom development
  • config – for configuration directives on how your site should behave
  • content – the folder which houses all of your actual content, formatted in Markdown files. Filenames are used as URLs by default, so your Blog page can live at either content/blog.md or content/blog/index.md
  • data – for storage of additional bulk content, not meant to output as standalone pages
  • layouts – theme files, usually written in HTML, and including shortcodes for dynamically inserting data. These control all global page sections (header, footer, navigation, sidebars, etc.), as well as per-page designs (Home, Blog, About, etc.)
  • static – storage of CSS, JavaScript, images, fonts, etc.
  • themes – if using a pre-made theme instead of a fully custom one (or if using multiple pre-made or custom themes), otherwise this folder may not exist
  • resources – for use by Hugo to cache (speed up) generation

Because flat files power the website content instead of a database, there is no distinction between site theme files and site content files. They can be version-tracked in a single location using a service like GitHub, and deployed to all of the usual suspects that support static site hosting – AWS S3, Cloudflare, and Netlify, to name a few.

Hugo vs. WordPress

The Hugo community, although a fraction of the size of the WordPress community, offers hundreds of starter themes you can include in your website, or use as a starting point to developing a fully-custom website. When it comes to developing themes for each platform, there’s a surprising amount of similarities in the hierarchies used for Hugo and WordPress.

As we’ve touted Hugo as an excellent option for simple marketing sites, the extended functionality provided by the WordPress plugin ecosystem is a major advantage over Hugo. True to its Jamstack lineage, Hugo leans on embedding scripts and third-party services (APIs) within the theme, and offers no back-end dashboard for managing these external functionalities.

Otherwise, Hugo’s simplicity directly correlates to lower overhead when deciding where to host your marketing site. Additionally, the flat file storage means your content is available to you in a single location, formatted in a language that nicely converts to (and from) Word and HTML, and that pastes nicely into any WYSIWYG editor.

Hugo & Netlify cms

While Hugo’s Markdown files are typically managed using text editors (or a specific Markdown editing application), savvy developers who host their Hugo sites on Netlify (typically for free) can leverage the Netlify CMS. The setup, while not a comparable replacement for WordPress’s Gutenberg editor, is superior to managing Markdown files ad-hoc.

https://www.youtube.com/watch?v=p6h-rYSVX90&t 

While it is outside of the scope of this article to go into further detail on setting up this implementation, the video above should help get you started, if you’re interested.

The takeaway

Jamstack sites aren’t for everyone, namely the faint of heart, and those who are more comfortable within the robust confines of the plugin/theme ecosystem offered by WordPress. But, for simple implementations, Jamstack sites such as the Hugo static site generator offer a full web experience for a fraction of the overhead of a WordPress site, particularly when it comes to paying for hosting.