Why I Built My Website With Zola Static Site Generator

Table of Contents

1. Summary
2. Intro
3. What Is A Static Website?
4. What Is A Static Site Generator?
5. SSR vs. SSG
   1. SSR (Server-side Rendering)
   2. SSG (Static Site Generation)
   3. Comparison
6. CMS vs. SSG
7. Why I Chose Zola SSG
   1. Eliminating Options
8. Conclusion
9. References

Summary

I wanted a simple, lightweight, static website, so I chose a SSG.

A Static Site Generator or SSG is a technology that helps you code dynamically, and then gives you static output. Meaning only simple HTML/CSS/etc. And after the build step, which turns your dynamic code into static assets, nothing is rendered on the server and there is no dynamic rendering on the client. It's like manually creating HTML pages like the old days, but gets rid of the redundancy and repetitive work and also makes your website much more maintainable and easier to edit or change.

From the different SSGs like Hugo, Vitepress, 11ty and Zola, I chose Zola because it has a good and easy templating engine, great docs, is easy to setup, and also is built in Rust, and since I like and know Rust, doing custom stuff in it will be more enjoyable and easier for me.

Intro

At first when I started programming and getting more involved with software and the web, I would get so excited by seeing websites with fancy animations and bells and whistles, like the websites you see on dribbble, or those Apple product pages with lots of animations. That was my standard for how a high quality website looks like, so flashy and charming.

But as I matured a bit into a software engineer and gathered more experience in the web and software world, I started to appreciate simplicity more, and more, and more. While back then, seeing a very cool scroll animation would make me WOW, now seeing a very simple HTML+CSS page that is super lightweight and very easy to use makes me WOW. Because when you strip all the animations, all the heavy CSS and JS, that's the real engineering product.

If your website works, feels and looks good without these distractions and crutches, (in my opinion) you have engineered and created a good website. And I think this is the case for any other engineering product.

For example let's talk about cars a bit. You can find cars that have so many options: cruise control, heated seats, an advanced computer to interact with, good looks, lots of bells and whistles, but after you drive 100K kilometers with them, they start to look absolutely trashed and it doesn't take much longer for them to fall apart and fail completely; You can also buy a well built Japanese car that looks like your grandma's purse, has no extra options whatsoever beyond safety and essentials, but after 100K kilometers this car still looks and feels new (assuming you take good care of it), and you can drive it for at least 400-500K kilometers. I go with the second option any day, and that is what engineering is to me. The first car is built by marketers, the second car is built by engineers and sold by marketers.

So I wanted to create my website as simple, lightweight and well built as I can, while still looking decent, and also avoid JS, or even if I had to use JS, I wanted the website to be still fully functional without it.

After some research I realized a static site generator(SSG) is what I want. But how did I come to that conclusion? Let's see.

What Is A Static Website?

A static website is made up of one or more HTML webpages that load the same way every time. Static websites contrast with dynamic websites, which load differently based on any number of changing data inputs, such as the user's location, the time of day, or user actions. While static webpages are simple HTML files that can load quickly, dynamic webpages require the execution of JavaScript code within the browser in order to render.¹

In short: static website = website comprised of simple HTML/CSS/image/... (static) assets.

What Is A Static Site Generator?

Let's think from scratch about how you would create a website in the beginning days.

You would create a page with HTML, your page had a header, some side bars, some content and your content can have a certain structure. Now if you want to create another page but with different content, you have to copy and paste from your first page and change the content (so you can maintain the same overall structure of header, nav bar, footer, etc.).

But just imagine how hard that is. And good luck if you want to refactor or change something; You have to change it in every single page.

And keep in mind this example is very basic. It can get way more complex.

So instead, what if I could code dynamically, but get static output?

This is exactly what a SSG does for you. You code your website dynamically and then it gets compiled into static assets that you can deploy on the web.

In cloudflare's words:

A static site generator is a tool that generates a full static HTML website based on raw data and a set of templates. Essentially, a static site generator automates the task of coding individual HTML pages and gets those pages ready to serve to users ahead of time.¹

SSR vs. SSG

SSR (Server-side Rendering)

Server-side rendering (SSR) is a technique for rendering web pages on the server-side before sending them to the client's browser. In SSR, the server generates the HTML content of a web page based on the requested URL and data, and sends it to the client's browser as a complete HTML document.²

SSG (Static Site Generation)

Static site generation (SSG) is a technique for building web pages by pre-generating HTML, CSS, and JavaScript files at build time instead of rendering them on the server or client-side.

In SSG, a static site generator tool like Jekyll, Hugo, or Gatsby.js is used to compile the website's content from data sources such as markdown files, JSON files, or CMS data, and generate a set of static files that can be served directly to the browser without any server-side processing.

The generated static files can be deployed on a web server or a content delivery network (CDN) and served quickly to the end-users with low latency. SSG offers several benefits such as fast loading times, improved security, and scalability.

Since SSG renders web pages at build time, there is no need to generate pages dynamically on the server or client-side. This reduces the processing overhead and enables faster loading times.²

Comparison

So with the above points being said, SSR and SSG are two different rendering patterns.

SSR usually means that the website is still interactive and dynamic, but the interactions get rendered on the server and then sent back to the client; The new HTML will be replaced by the old one.

SSG means the end results are a bunch of static assets, And nothing will be rendered on the server after you have compiled and built your website and deployed it.

Your SSG result is a static website (as opposed to dynamic).

So while it's true that the client receives static assets both from a SSR and SSG website, the difference is between the end results still being dynamic and rendered on the server in a SSR website, and the end results being fully static in a SSG website.

CMS vs. SSG

"Ok so it helps me create and manage my website more easily and efficiently by eliminating redundant work, so I can mostly focus on the content. Isn't that what a CMS(Content Management System) does too?"

Well kind of, but lets see how cloudflare explains a CMS¹:

In the early days of the Internet, websites were stored as static HTML sites, with all webpages laid out and hard coded in advance. This was inefficient because it required developers to code each webpage manually.

Content management systems (CMS) emerged as a way for developers to avoid all that manual setup. Instead of coding the pages ahead of time, content is stored in a CMS database, and when a user requests a page, the server does the following:

1. Queries the database for the right content
2. Identifies the template the content will fit into
3. Generates the page
4. Serves the page to the user

Content in the CMS has to fit in one of the fields offered by the CMS database, but as long as it does, it should appear in its proper place on the website every time.

A static site generator is a compromise between these two approaches. Like a CMS, it allows developers to use templates and automatically generates webpages — but it does the latter ahead of time, instead of in response to a user's request. This makes for faster website performance, because the webpages are instantly ready for delivery to end users.¹

While what couldflare said isn't wrong, this is the explanation for our classic CMS like wordpress, joomla, etc.

The whole question of "CMS vs. SSG" is a wrong question. These are two different things and comparing them is like comparing apples and oranges.

CMS is "Content Management System", and SSG is "Static Site Generator". So you can have a CMS for your SSG! Projects like Siteleaf and Static CMS do exactly that.

But most of the time, you don't need a CMS for you SSG because it's already pretty straight forward. But some use cases that I can think of for SSG+CMS is for example when your organization's website is built with a SSG and you want all colleagues, even the non technical ones, to be able to write blog posts very easily and manage the content more easily.

So why didn't I use something like wordpress?

1. Because I wanted a static, lightweight website
2. I wanted customizability. With something like wordpress you stay very limited.
3. I have created and maintained wordpress websites and nothing is more frustrating than creating a blog post or content in wordpress. With most SSGs, you can just use markdown for you your content which is much more maintainable and much easier to write.

Why I Chose Zola SSG

Now that I knew I wanted to use an SSG, I had to choose one.

The most attractive options to me were:

• Vitepress -> Since I'm very familiar and good with Vue and Vite
• Hugo -> Heard it's name a lot, and seen many websites that caught my attention using it
• 11ty -> Looked cool, very flexible and had great community
• Zola -> Also looked cool, good and straightforward docs, and built with Rust (I'm a Rust fangirl, sorry)

Eliminating Options

Vitepress got eliminated because it generates SPAs and uses JS on the client side to hydrate the page content. While I still use it for docs in our organization and think it's great, it didn't fit my needs here.

11ty looked cool, had a great possum mascot, and was very flexible. But being very flexible and DIY was also a downside for me since I didn't want to wrestle too much with the website and focus more on my content. Also, the docs seemed kind of scary and confusing.

It came down to Hugo vs. Zola.

Hugo is super popular, has very big community and is well maintained, it's super fast on builds, has great docs, and is focused on blogging.

Zola was also very on par with Hugo. It's Blazingly™ Fast(Rust, obviously!), very good and simple docs, easy to setup and is focused on contents.

Also, both Hugo and Zola are installed using a single binary file which makes the dev experience much better.

The main points that made me choose Zola over Hugo were:

• Hugo uses Go's html/template and text/template which are said to be very odd and hard to learn.^{3 4} But Zola uses the Tera templating engine which has very sane syntax and is more straightforward.

• Zola is built with Rust, and I really like Rust, So if sometime I have to do some deep customization, I will have to deal with Rust instead of Go which is a plus for me. And even if I find something is wrong with Zola, I might be able to fix it myself and create a PR, since it's in the Rust ecosystem.

• If something is super popular, I kind of lose my interest in it. I tend to always love underrated things.

Conclusion

This is how my website looks like at the time of writing this blog post(since it might change in the future). I created it using the Duckquill theme.

This is my second blog post, and up to this point I'm very happy with my website and Zola.

References