I talked about static site generators (SSG) and server-side rendering (SSR) in my previous blog post. We cover a brief history of how various techniques of websites and web-based applications were created and their intended use.
But, as we say in the Tel-Aviv HQ – “let’s talk Tachles” – what is the difference between the names I mentioned in the previous blog post? Where one shines, and the other is just a dimmed light in the dark? I’ll try to go over the ones I used through the years and show you the weaknesses and strengths of each.
But, before we start, let’s remember what SSGs are and how they do what they need to do. SSG has one purpose in life – take raw data that we store in files (markdown, YAML, CSV, JSON, etc., etc.) and convert it into static HTML files to serve them very easily without any DB or a live HTTP server that serves files.
4th place – Jekyll
Yes, you might say, “Jekyll at 4th place? It was the first one and paved the way,” and you are correct! It has its own templating system and uses many ruby libraries to get stuff done means it might not be the proper tool for a developer outside the ruby ecosystem.
3rd place – Hugo
Hugo was the next SSG I used, and I can say it’s fast. Very fast. When dealing with image compression and compiling the site to HTML, the performance was over the bar for what I know in SSG.
There is no significant difference between Jekyll and Hugo in terms of data sources—both of them have CSV, JSON, etc. The main difference is the template engine, but they have similarities to any existing template engine.
Expand Your Test Coverage
2nd place – NextJS
NextJS is not just an SSR or SSG; it’s something more. It’s a complete framework for React, and you might want to choose it instead of the traditional CRA. NextJS comes with a built-in router, HTTP server and can get you to a production site in no time.
Unlike Jekyll or Hugo, there’s no unique template engine since this is a React-based framework that makes any front-end developer feel at home. There’s no limitation regarding the data source types; NextJS provides a hook where you can prepare the data, including fetching data from an API endpoint, reading from file… anything you can do with NodeJS.
1st place – GatsbyJS
When building a content-based site, GatsbyJS comes with a lot of features that resemble NextJS: routing system, SSR or SSG, and more. The critical difference is the approach—GatsbyJS is much more opinionated than NextJS, and you need to follow an API set to get what you want.
But, when coming to build content base sites, Gatsby does better than the rest. While Hugo and Jekyll read from files and NextJS requires you to create the data fetching yourself and provide it to NextJS via a hook, GstabyJS takes another approach.
GatsbyJS can connect to any data source – files, various CMSs, GraphQL/REST endpoints, or anything you can imagine and provides you an excellent interface to query those sources and see how the data is retrieved. In addition, there’s a quick button that scaffolds a React component (class or hook-based), and all you need to do is just save it to a file.
Testing a static site
Testim shines when it comes to creating simple E2E testing for complex sites. However, SSGs are simple sites with no backend, just displaying static content. Often companies will have a mix of static and dynamic sites and can take different approaches to each. Regarding static sites, Testim can still provide value in the following two ways:
Test the links and content
You can verify that a title or subtitle is displayed; When clicking on a link, you can confirm we got redirected to the correct place. It might sound trivial, but you would like to know that the “contact us” link takes the user to the contact information in the footer.
Pixel validation
With pixel validation, we can verify that the design of the site is applied correctly. For example, we might want to test that the title of a page appears correctly. Unlike a web-based application where we need to focus on the logic, in this case, we focus on the visibility of the site.
Conclusion
While static sites might not be for every organization, they do have their place. We hope you found this quick review of SSGs useful and have a better idea of selecting the appropriate tools to help you build and test them.
