Why we rebuilt this website with Zola
2024-11-21
Where we started
Until recently, the Arrillo website had been running on Angular. You might think that was a strange choice for a business landing page style website. The reason we used Angular initially was because we were familiar with it, and it was very fast for us to get started and get the website live. Angular has server side rendering within the build chain now, much like next.js. There was one major downside though, adding new pages was not the fastest - adding new components and linking everything up would always lead to some re-crafting of the website or general tinkering with node modules, build systems etc.
The beauty of standardization
The best thing about a blog is that each page is structured the same way. Readers know what to expect, and you don't have to waste time thinking about how you lay out and deliver each message. This means that lots of businesses end up with WordPress websites as it is a simple way for a non-technical user to achieve this standardization, even though they don't really want to use blogging software.
Within Zola, specifically Tera - Zola's templating engine, you get all the functionality you could ever need to create dynamic templates. This gives you the standardization and speed of deployment from blogging software, without the massive overheads incurred from running or managing a blog server, plugins, templates etc.
For example, In Zola you start by creating blocks for your template, these can be very simple, or as complex as you want with logic and variables:
<head>
<title>{% block title %}{% endblock title %}</title>
</head>
<body>
<section class="main-content">
<div class="container">
{% block content %} {% endblock %}
</div>
</section>
</body>
Once you have your template, making a new page is as simple as creating a new markdown file:
+++
title = "New Arrillo Product!"
date = 2024-11-01
+++
We have a great new product to share with you!
The simplicity in this approach means we now commonly recommend Zola as a great option for any static website project, because inevitably new pages will be added further down the line.
By completely separating the content from the design and functionality, this significantly speeds up the deployment pipeline, especially when a new page might have to pass through various teams or departments including: Subject-matter experts, copywriting, graphics, marketing, and technical teams.
Each page is a blank canvas for innovation & testing
By moving back from a Single Page App to statically delivered pages, each URL is its own opportunity to use the right tools for the task at hand. We no longer have to load in additional JavaScript, fonts or assets that might be used in an unrelated part of the website. This is especially helpful for us as we work with so many different technologies, we have the option to include libraries and frameworks only on specific pages. If we are showing off new features of some interesting web technology like React, Tailwind, or whatever cool new thing everyone wants to use, then we can load it into just that single URL, making every URL a unique place to experiment! This is the second-best part about moving back from a JavaScript based SPA, the best part is:
Zola is REALLY fast
Done in 29ms.
Being used to a JavaScript toolchain: starting, building, and serving with Zola is incredibly refreshing! With reload times in milliseconds it's an absolute joy to iterate on. With the creation of Bun we started to get a glimpse into how much faster our toolchains can be with statically compiled components, and this is going to be a focus for us going forward. A fast toolchain allows for faster iteration, and with Zola, we love to see it!