83bef6955e
e161ea09d Add one more Chinese file to workaround reflect: Zero(nil) b595b3a21 Add more Chinese translation 56e4e95d9 Use lang.Merge to "fill in the gaps" for untranslated pages ef079406c Merge commit '650fac3a4e7d256f4505402ab44cfc3c804b8dea' 650fac3a4 Squashed 'themes/gohugoioTheme/' changes from a1768ebb..f31a3dc8 322eff899 Add Chinese language for menus d90b886e0 Fix Markdown table syntax in previous commit 737f3dfca Update the leaf bundle vs branch bundle table 09fa1bc4e Clarify that `.Now` is obsolete 879ea3f6a Make release notes somewhat more consistent 0113e2051 Move 0.40.2-relnotes into content/en/news 77578f5bf Move content/ into new contentDir content/en/ 4dcf7c709 Fix "reflect: Zero(nil)" error in showcase 63dd25505 Release 0.40.2 2076c0d56 releaser: Prepare repository for 0.41-DEV 070fe565e releaser: Add release notes to /docs for release of 0.40.2 4ce52e913 releaser: Bump versions for release of 0.40.2 41907c487 Fix typos in syntax-highlighting.md 91753ef3d Add missing backtick b77274301 Remove duplicate release notes (0.27, 0.27.1, 0.35) 6e00da316 Remove obsolete content/release-notes/ directory 00a6d8c02 Change en dash back to `--` in 0.38.2-relnotes 51b32dc00 Update archetypes.md d0e5c2307 Release 0.40.1 4538a6d5b releaser: Prepare repository for 0.41-DEV 91b391d70 releaser: Add release notes to /docs for release of 0.40.1 e0979d143 releaser: Bump versions for release of 0.40.1 7983967c2 Clean images fe3fdd77d Polish showcase for Flesland Flis e6dde3989 Showcase - Flesland Flis AS by Absoluttweb 73aa62290 Revive @spf13's special Hugo font add67b335 Release Hugo 0.40 c0a26e5a6 Merge branch 'temp40' beeabaaae releaser: Prepare repository for 0.41-DEV e67d5e985 releaser: Add release notes to /docs for release of 0.40 6cdd95273 releaser: Bump versions for release of 0.40 bee21fb9b Revive the other Hugo logos too 4f45e8fe1 Fix the link type attribute for RSS in examples 8c67dc89a Fix example in delimit doc e7f6c00d5 Revive the logo used on the forum 82b0cd26e Merge commit 'a215abf70e018f4bf40d6c09d8bd148d8684b33d' 119c8ca58 Merge commit 'd2ec1a06df8ab6b17ad05cb008d5701b40327d47' db4683bd2 Improve .Get docs 05260b886 .Get function: fix syntax signature git-subtree-dir: docs git-subtree-split: e161ea09d33e3199f4998e4d2e9068d5a850f042
6.2 KiB
| title | date | description | siteURL | byline | draft |
|---|---|---|---|---|---|
| Small Multiples | 2018-02-28 | "Hugo has excellent support and integration with Netlify and we were immediately blown away by how fast it was." | https://smallmultiples.com.au/ | [Small Multiples](https://smallmultiples.com.au/) | true |
Previously we had built and hosted our website with SquareSpace. Although SquareSpace was adequate for quickly showcasing our work, we felt it didn’t reflect our technical capabilities and the types of products we build for our clients.
For many client applications, static front-end sites provide fast, scalable solutions that can easily connect with any back-end service, API or static data. We wanted to use the same processes and infrastructure that we use to host and deploy many of our products, so we felt that building a static site was the right solution for our website.
Netlify is a hosting and deployment service that we use for many products. Our developers really like it because it has strong integration with GitHub and it works with the build tools we use such as Yarn and Webpack. It creates a production build every time we commit to our GitHub repository. This means we can share and preview every change internally or with clients.
Application development has become increasingly complex and there is a strong motivation to simplify this process by avoiding complicated backends in favour of applications that consume static data and APIs (a JAMstack).
Libraries like React make this easy, but we also wanted something that was server rendered. This led us to look at React based tools for static site generation such as GatsbyJS. We liked GatsbyJS, but in the end, we didn’t choose it due to the lack of availability of a simple CMS driven data source.
For this, we considered Contentful. Contentful is a beautifully designed application. It’s basically a headless CMS, but it’s not specifically designed for websites and it becomes quite expensive at a commercial level. Their free tier is possibly a good option for personal sites especially with Gatsby. We also evaluated prose.io. This is a free service for editing markdown files in a GitHub repository. It works well, but it’s quite basic and didn’t provide the editing experience we were looking for.
At the same time, we started exploring Hugo. Hugo is a static site generator similar to Jekyll, but it’s written in Go. It has excellent support and integration with Netlify and we were immediately blown away by how fast it was.
We had been closely following the redevelopment of the Smashing Magazine website. We knew this was being powered by Hugo and Netlify and this showed us that Hugo could work for a large scale sites.
The deciding factor, however, was the availability of CMS options that integrate well with Hugo. Netlify has an open source project called NetlifyCMS and there are also hosted services like Forestry.io. These both provide a CMS with an editing interface for markdown files and images. There is no database, instead, changes are committed directly back into the GitHub repository.
In the end, we chose Hugo on Netlify, with Forestry as our CMS. The site is built and redeployed immediately with Netlify watching for changes to the GitHub repository.
Was this the right choice? For us, yes, but we learnt a few things along the way.
The Hugo templating language was very powerful, although also frustrating at times. The queries used to filter list pages are concise but difficult to read. Although it’s easy to get started, Hugo can have a significant learning curve as you try to do more complicated things.
Hugo has particular expectations when it comes to CMS concepts like tags, categories, RSS, related content and menus. Some parts of our initial design did not match perfectly with how these work in Hugo. It took some time to figure out how to make things work the way we wanted without losing all the benefits of structured content.
There were a few teething issues. We picked some relatively new technologies and as a result, we encountered some bugs. We were forced to find some workarounds and logged some issues with Hugo during the course of development. Most of these were fixed and features were added with releases happening frequently over the time we were working on the project. This can be exciting but also frustrating. We can see Hugo is developing in the right direction.
NetlifyCMS was also very new when we first looked at it and this is partly why we opted for Forestry. Forestry is an excellent choice for an out-of-the-box CMS and it needs very little code configuration. It provided a better editing experience for non-technical users. I would still say this is true, but it also provides fewer options for customisation when compared with NetlifyCMS.
Fortunately, the site is more portable now than it was, or would have been with a dynamic CMS like WordPress, or a fully hosted service like SquareSpace. It should be comparatively easy to swap the publishing functions from Forestry to NetlifyCMS or to change the templates. No part of the pipe-line is tightly coupled, the hosting, the CMS and the templates and the build process can all be updated independently, without changing anything else.
We have complete control over the design and mark-up produced. This means we can implement a better responsive design and have a stronger focus on accessibility and performance.
These technology choices gave us a good performance baseline. It was important to implement a site that took advantage of this. As a data visualisation agency, it can be difficult to optimise for performance with a small bundle size, while also aiming for high-quality visuals and working with large datasets. This meant we spent a lot of time optimising assets making sure there was little blocking the critical path for faster rendering and lazy-load images and videos.
The end result is a high performance site. We think this could have been achieved with GatsbyJS, Hugo or any another static site generator. However, what was important was the decision to use static infrastructure for speed, security, flexibility and hopefully a better ongoing development experience. If you are looking at choosing a static site generator or wondering whether a static is the right choice for you, we hope this has helped.