Part one in a three-part series on how and why I built this site with the Eleventy static site generator.
Earlier this year, I went full-time freelance (common 2020 story? 😂). As I was thinking about how I wanted to run my own little business and looking at the kind of work that I most enjoy, I decided to focus the next stage of my career on web design and front-end development.
Most of my career so far has focussed on brand identity design and all the supporting graphic design that goes with that.
But over the years I have had quite a few opportunities to design websites and even do a fair bit of basic front-end development. But I mean, pretty basic development stuff. Mostly just vanilla HTML, CSS and Javascript. Static webpages. A little bit of WordPress customization. But I loved it. And seems like a smart career direction. So that's what I'm doing now.
I realized that my development experience was still relatively minimal. So I decided to use this website build as an opportunity to learn some more advanced front-end stuff.
I had already read quite a bit about static site generators (SSGs) and had even dabbled a bit with Jekyll and Github pages. The idea of SSGs, and their pros, really spoke to me. I also generally dislike WordPress. I don't like the idea of having a big ol complicated server and sprawling MySQL database (that I can't easily read/hack myself) just to run this little internet website.
And so I decided to use a static site generator, hosted and served up on Netlify, for developing my site. There are so many to choose from, but in the end, I decided to go with Eleventy (11ty).
but what the balmy-heck is a static site generator?
It's a piece of software that generates static websites... 😉
First, we need to understand the opposite of a static site: a dynamic site. For a while now, many websites have been what we call "dynamic". This means that when a person browsing the internet lands on a page of your website, the server that your site is hosted on will automatically do a bunch of on-the-fly magic to compile the page that the user has requested and send it back to their browser. The page isn't already built, waiting to be viewed. It is only built when it is requested. It is pulled-together using a bunch of different templates, components and content that the developers and designers have prepared in advance.
This is desirable because developers can then write a template or component just once, and tell the server to use it many times over on different pages as needed.
For example, the header bar and navigation menu at the top of most websites. Instead of coding that bit of the site for every single possible page on the site (or copying and pasting over and over), it can be coded once and then told to be "included" on each page of the site programmatically by using a template. This reduces the time spent coding and also the chance for human error. It also makes it much easier to fix a bug. If the link to the about page is broken, you only have to fix it in one place!
The "dynamic" part is referring to how the server will only compile all the parts of a page at the time of the request from the viewer. If no one requests a page, it will not be built.
A static generated site is very similar in concept. It will still use templates, layouts and components that are coded once, then compiled into the various pages that need them. The primary difference between static generated sites and dynamic sites is when the compilation takes place. With a static site, all possible pages in the entire website are compiled at build time. Well before a user requests to view a page.
This means that when a user lands on a page of your site, that page is ready to go. It doesn't have to be built while the viewer waits.
There are pros and cons to both dynamic sites and static generated sites.
three of the big pros of static sites:
- Potential for much faster page load times (because the page is already built, it can be sent to the viewer right away)
- Increased web page security (the infrastructure and processes needed to serve an already-rendered static site can be much simpler than that needed for a dynamic site. Simpler infrastructure leads to fewer potential points of attack).
- Reduced server load which can result in reduced server costs, especially in the case of sites that get a ton of visitors at the same time (think large eCommerce).
a few other aspects of SSGs that appealed to me:
- No need for a database. My content can live as markdown in a GitHub repo (like this blog post!).
- Most SSGs don't have a GUI or easy-to-use interface. You need to know how to edit some code and use the command line a bit. This forces me to practice those developer basics.
- SSGs aren't new, but they seem to be having a moment as the tools have greatly matured and improved in recent years. It feels like a good thing to learn right now.
so why eleventy?
- It's lauded and recommended by JAMstack leaders and big names in the web dev world.
- It's un-opinionated, meaning that I can use a folder structure and template format that makes sense to my brain or makes sense for the project.
- It can be very simple with not much needed to get a basic site up and running. But can also tackle complex sites with many nested layouts and logical templates.
- It has a charmingly unpretentious website with a hilariously weird logo.
- The people who make it seem to care about good things
That's it for today. Look out for part 2 where I talk about the specifics of my own Eleventy build and show-off just how ignorant I am.