# Dipping my toes into jamstack

URL: https://olli.works/blog/dipping-my-toes-into-jamstack | Published: 2020-12-23 | Tags: development

> Testing the development experience of Hugo + Forestry CMS

As I've worked so many years with WordPress, I wanted to try out something else. I had heard fuzz about Jamstack and its benefits but never had any project where I could give it a shot. Late 2020Q4 I decided that I finally need my own website and what better way to build it than with something new!

I have wanted to try out Jamstack already for a while but I didn’t know what to do. After seeing my friend’s site built on Hugo, I decided that I want to try it out as it’s based on Go, the new programming language created by Google. I still had to have some sort of CMS to handle the content and I wanted to do something else than WordPress, Forestry CMS seemed to be the obvious choice according to several sources on the web.

**I had certain requirements that I wanted for the setup:**

* Easy handle separately posts and pages
* Support for custom blocks which can be put in any order
* Posts/pages built on custom blocks
* Querying only certain content/filtering content depending on variables

## Prerequisite

Out of the box, I didn't see any Hugo solution for the custom blocks, but once I read onto Forestry's Front Matter of reusable front matter elements, I knew I had to give it a shot. At this point, I started building my own Hugo theme by emptying a readymade theme to barebones.

I brought in many of the SCSS-mixins and variables which we are using in Evermades open-source [Everblox theme](https://github.com/evermade/everblox "Everblox theme"). These tidy up things and make it faster to develop elements.

## Post listing issue

Listings turned out to be a little tricky. Hugo uses several different archive pages for automatic content generation. This was neat but not really what I was looking for, so I had to figure out how to custom query content with Hugo to create a post listing. After debugging post-fetching for many hours I realized that I need to change the way I'm thinking. I was stuck in the PHP-MySQL mentality where you only fetch what you need, but with Hugo, it doesn't matter as much how optimized your post-fetching query is as the final result is anyways a static site. I ended up for a less-optimized solution to be able to move on. I'll maybe revisit this again sometime in the future

## /content/ folder

One thing which I fell in love with was that all the content (excluding images) are saved in the git-repo itself! This made it super easy to sync up to where I last stopped, as I've worked on this from a few different computers. In WordPress, you always had the issues with transferring databases and renaming URLs, but not with Hugo!

## Working with Forestry CMS

The text editing experience is a slight downgrade from WordPress TinyMCE as the Forestry CMS editor does Markdown. This makes the content cleaner, but you lack any specialities eg. adding custom elements/tables to content. The markdown still supports raw HTML so you can still do whatever you like, it just won't look as tidy in the CMS.

## Image hosting

As all the content is saved in the git repo, I had to figure out how to host the images. In WordPress, you have nifty shortcuts to get the right size of an image but Forestry lacks anything similar. I first thought about AWS but found out that Netlify offers Git LFS (Large File Storage) with additional parameters for the compression. With this, I was able to set maximum-resolutions for all my content. This way I don't have to worry about uploading too large images and can focus on making great content.

## Workflow

During the development of this site, I’ve changed deployments and even tried Hugo modules. Finally, I settled on Git submodules as those were simpler to work with. Now my workflow works like this:

### Want to edit content?

Go to Forestry.io and edit the content, Netlify build and deployment happen automatically after a save.

### Need to edit features/blocks?

My Hugo-theme is in its own repo so it doesn’t trigger automatic deployments. I can develop it further, and when ready, commit the Hugo-site repo with a new submodule hash which triggers the Netlify build and deployment.

### Debugging or further development?

I just need to have the Hugo-site repo with the Hugo-theme submodule fetched, and I’m ready to debug things with the command **hugo server**.

## Final verdict

Overall Hugo + Forestry has surprised with some features, some again have been a little letdown. If you want to build a static site with a CMS, this works for more simple cases really well. If you need some more robust content editing tools, I suggest looking at some other CMS\:s which can deliver on that.

## See my other development projects