A while ago – in April 2015 – we launched bugtrackers.io as a small side project. Since then, the site has grown from a three-pager to a website with dozens of interviews.
The increasing number of pages & therefore line of code made us look for ways to improve our internal workflow.
We also ended up using GoHugo as our main website framework for bugtrackers.io. In this post I’m going to share some of our first experiences with GoHugo as well as our path to ending up where we are right now.
To the recap.
Before I show you how we transferred bugtrackers.io to Hugo, I want to give you an overview of our setup.
Basically, we added Hugo as our static site generator. Why? Keep on reading…
* Though I have to add that this workflow might change soon in the future, since divshot was acquired by Google and is closing its service.
The Role of Hugo.
So, what role does Hugo play in our website setup? Hugo is an open source static site generator. Static site generators build a web page once, at the moment you’re creating new content or editing it.
In contrast, content management systems like WordPress build a page every time a visitor requests one (although there are various caching techniques available). There are a lot of advantages and benefits to choosing a static site generator like Hugo over a system like WordPress.
And those advantages are not only about performance.
Hugo also comes with a watch mode which automatically refreshes web pages while editing them. Originally, Hugo was started as a side project by Steve Francia. Today, the Hugo community has more than 165 contributors, 35 themes and thousands of users.
Why a static website builder?
So you might wonder: Why does someone need a static website builder? Right, good question.
As you probably know, in its early beginnings, the web was the place of static web pages. So why would one want to go back to that state if there is WordPress, Ghost, TYPO3 and many other CMS out there?
Here are the most important benefits of a static site builder. They are the the ones we considered for our website bugtrackers.io and the reasons why we ended up using Hugo.
Performance: Speed it up.
One of the biggest benefits of having a static site is definitely speed. Static websites are incredibly fast, especially when compared to sites that carry all the burden of a heavy-weight content management system.
Pro tip: static sites can and should also be distributed on a CDN. Since your website consists of just static content, it makes sense that it is cached at several locations around the globe. For example, by using AWS Cloudfront.
Static web pages give you 100% control over your content and web design. If you’re planning on producing various landing pages with different designs, it especially makes sense to consider a static site generator and not a CMS like WordPress.
We’re not only working with Hugo for bugtrackers.io but we might also eventually shift our landing page at usersnap.com to Hugo using the described workflow.
Because Hugo is all about static sites, it lacks fewer security issues. There’s nothing to be exploited on the server-side. No php running. Nothing. This makes static sites quite stable against security breaches.
Thanks to HTML5 our static sites can be more dynamic than ever.
Let the times of form submits as a major pattern pass by and join the future. There are already lots of great 3rd party services such as customer care snippets (Intercom.io, Olark), website feedback (Usersnap 😉 ), exit intent services (AddThis), analytics (Google Analytics, heap.io), social services (AddThis) and many more waiting to enrich your websites.
Drawbacks: static is static.
With so many benefits, there might be one or two drawbacks as well when using Hugo as your static site generator.
No UI for non techies.
OK, I get it. Nowadays, publishing blog posts on WordPress or Medium is super simple. And that’s great. You can publish anything from anywhere in the world without any programming skill needed.
I guess that’s not really the case with static site generators like Hugo. We use Atom as our main text editor. To publish new posts or files you need to re-generate the web page and deploy it to a server. That may be a bit of a challenge if you’re not that tech-savvy.
Hugo isn’t as mature as other static site generators. But it has a lot of potential to get there.
We’ll see how the project will evolve as there are still a lot of feature requests and work to do. Some template and variable functionality aren’t as handy as with more mature projects. Following the discussion thread of Hugo, this is a subject the community is already working on.
Additional tools required
As mentioned, Hugo is open source and can be installed quite easily. Go to the Hugo GitHub repository and watch out for the installation files. If you’re on OSX, you can use Homebrew to install Hugo:
brew install hugo
After installing Hugo, you can use Hugo in the command line.
Now let us make a directory for Hugo to work in, and tell Hugo to make a new skeleton site there:
$ hugo new site website $ cd website
Hugo will then automatically generate a directory structure:
▸ archetypes / ▸ content / ▸ layouts / ▸ static / config.toml
You have now created the first pieces of your static web page. If you want to create a new page, simply use:
$ hugo new about.md
If you don’t want to create your own layout, I recommend checking out the available Hugo templates and just use of one of them.
Update: Our main website runs on Hugo too.
After our mostly great experience with Hugo for bugtrackers.io, we decided to give it a try for our main website too. A couple of months ago, we started a relaunch project for our website usersnap.com. And early on, it was clear to use new frameworks which we successfully used for bugtrackers.io.
Bugtrackers.io is a pretty lean and simple website compared to usersnap.com. Making usersnap.com Hugo-ready required us to put our heads together and over-invest in the Hugo setup. There were a lot of bugs and issues which I guess simply occurred because we used Hugo for the first time for such an “expansive website”.
You can read our entire experience and lessons learned from relaunching our website in this blog post.
Wrapping it up.
Switching to Hugo has been an interesting experience for us so far. Hugo has proven to be reliable as well as scalable. As mentioned before, Hugo might be our go-to-tool when we start working on our next project, updating our technology base for usersnap.com. But that’s another story, so watch out for that!
What’s your experience with static site generators like Hugo?
PS: If you’re planning on making the switch to Hugo from WordPress or any other CMS, you should check out this page. There is probably a tool for exporting your content from your CMS to Hugo 😉
This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.