Zellwk.com is now open source!
I decided to open source my blog. You can see the source code (for almost everything, except credentials) over at this Github repo.
Why I open sourced my blog
I was afraid to open source my blog. I didn’t want people to dig through my code and point out what I did wrong. (It’s quite intimidating!).
But I’ve decided to open source my blog in the spirit of sharing and of writing dirty code. I hope you enjoy and learn from what I’ve created.
Zellwk.com is unique
- A static-site generator
- A node backend
Zellwk.com is unique because most statically-generated sites don’t use a backend. They’re primarily served through Github, Netlify, or other platforms.
I use a static-site generator because:
- Static sites load fast
- There’s no need to create a database
- They’re easy to maintain
- They’re easy to publish
I added a node backend because:
- I wanted to redirect people to a 404 page if a page isn’t found.
- I wanted to integrate my site with features I thought about (some of them requires a backend).
- I thought it’ll be fun and cool.
Tools I used to build zellwk.com
Tools I used include:
- Eleventy (a static site generator)
- Gulp 4 (a task runner)
- Sass (for CSS)
- BrowserSync (for live-reloading)
- CircleCI (for continuous deployment)
- Jest (for writing tests)
- Node and Express (for the server)
I encourage you to play with the source code to find out more about this repo if you’re interested.
Why I chose these tools
Many developers have problems choosing the “best” tool to use. I want to share my decision-making process to help you choose a tool that suitable for your project.
I ran zellwk.com with a custom static-site generator (let’s call this CSSG) I built with Gulp for two years now. My first and obvious choice was to continue using CSSG.
But I had a problem: I couldn’t test the features I built for CSSG. I was afraid to add additional features (like RSS and Tags, which are coming back to zellwk.com!). I wanted to improve zellwk.com, so I needed a static-site generator I can trust.
Switching over to this static-site generator needs to be relatively painless.
At this point, I heard great things about these static site generators:
I didn’t choose Hugo because I didn’t want to learn Go. It was too much work to redo my site.
I didn’t choose Gatsby because I wasn’t a React fan. I was using Nunjucks. I didn’t want to switch to React.
I chose Eleventy because Eleventy allowed me to use Nunjucks. The switch was relatively painless (still took me a week to make the switch though!).
I used Gulp 3 to run CSSG previously. It was a no-brainer to continue using Gulp to build my site.
I upgraded to Gulp 4 when I rebuilt zellwk.com with Eleventy because I wanted to understand the difference between Gulp 3 and Gulp 4.
This was unnecessary work. But it was work I was interested in.
Here, I discovered Gulp 4 had a simpler API, which means I have an easier time writing plugins to improve my build processes. For example, I built a plugin that resizes images to various widths. I’ll talk about this plugin in the future when I’ve solidified everything.
I’ve always been writing Sass. There’s nothing wrong with it, and there’s no reason for me to change.
But I wanted the ability to
import packages I downloaded through npm. To do this, I needed to use a tool like Browserify, Webpack, Rollup or Parcel.
Here, I chose Webpack because I already invested a considerable amount of work into understanding Webpack. I tried switching to Rollup and Parcel, but I couldn’t get them up in 20 mins (so I gave up and stuck to Webpack).
I decided **it wasn’t worth my time to try something similar **if they didn’t work immediately. I could use the time elsewhere.
Browser Sync is amazing. It lets you do two things:
- It reloads your website automatically when you change a file.
- It synchronises your website across multiple devices for quick mobile testing.
I love it so much I want to keep using it.
If you’re interested, this article on CSS Tricks shows you how to set up Browser Sync with Gulp.
It’s always a stressful moment to deploy ANYTHING to a server. I wanted to reduce this stress as much as possible by using a continuous integration (CI) tool.
What this means in simple language is:
- I commit my files
- Do a
- The CI server updates my site
There are many CI tools out there. Examples include:
I’m not sophisticated enough to spot the difference between CI tools. I picked the one that looked easy to begin with.
I tried many testing frameworks, including:
I love Jest because:
- You don’t have to configure it.
watchmode runtime is pretty sweet. No other tools have this!
- (Also, because Kent C. Dotts recommended Jest over AVA, and I felt its a chore to set up tests for new projects for AVA).
Node and Express
I continue to use Node and Express because:
- I was already using it
- I knew Node + Express backend
- I didn’t want to learn anything else right now
So there you have it.
Everyone has a different definition of what’s “better”. For Zellwk.com, I chose to use tools I’m already familiar with. I don’t want to spend extra time learning similar things.
Hope you have fun going through the repository!
Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!