Introduction
When I first had an idea about creating a blog sometime during lockdown, it was a simple thing that I had in mind. Create a child theme with one of WordPress' starter themes, make the style changes I needed and call it a day. I knew it wouldn’t be a bad choice because WordPress offers every thing I would ever need in order to manage a simple blog like this one.
However, the days soon went by and I got busy with work, so the thought of creating a blog was put to the back of my mind. I had already worked on the mockups for the blog and even had a WordPress custom theme built from scratch for it, but a few things remained to be done. Then there was also the matter of purchasing a server for it. I already maintained quiet a few at work and setting up a new one and managing it was not really that appealing to me.
What Next?
Then one day, I was called upon by my almamater to conduct a workshop on the basics of web programming and I accepted the offer. I created the slides for it in HTML and when I had to hand the slides over for future reference, I figured that hosting it someplace would be an ideal resource for all.
I had a couple of options to host these files - there was the usual shared hosting like GoDaddy and so on, or I could go the VPS or cloud route with something like Digital Ocean, or Amazon AWS or something along those lines. I had been hearing of Linode a lot lately as well, so I figured that was an option too. But the thing was that all of these requried that I do some form of maintenance from time to time - VPS solutions would require that I update the system packages, while shared hosting required that I login yearly once to renew the hosting. It was too much hassle for static HTML and CSS files that I would probably not even touch for years down the lane.
It was then that I stumbled over Netlify. With Netlify, I could simply just host my Git repository and it would be served through Netlify’s Content Delivery Networks. I could just connect the repository, point a domain name and totally forget about it. Simple, easy, and free.
Now, many of you might already have noticed that Netlify is something similar to GitHub Pages. Well, it is exactly that, with little to no difference in behaviour.
A New Home For My Blog
Since I didn’t want to go the WordPress route for the time being, I was willing - no, wanted - to try this new system of hosting websites. Of course, before content management systems actually became a popular thing, people used to edit HTML and CSS files and upload them to the server as new things were added. This is how a lot of the early blogs worked, and it is what a lot of the more simpler blogs prefer to opt for in modern times.
Static site generators are nothing new either. Tools like Jekyll have existed for ages now, and have eased the process of managing and maintaining a simple blog since the time they were initially created.
But the problem is that Jekyll is written in Ruby. It’s a language I have never worked with (apart from when I wanted to learn it back in 2012), and the other static site generators like Hugo, Gatsby and so on were all still written in other languages (Hugo in Go, and Gatsby in JavaScript and React). Even if I knew some of these languages, the tools themselves had a slight learning curve that I didn’t want to get into.
So, another roadblock. What next?
What next indeed. I spent the next couple of days wondering if I should spend the time learning some of these static site generators, but I always balked at the learning curve these had for maintaining a simple blog.
It was then that I decided to see if I could do all of this with tools I already used. I used Gulp for building my CSS and JS assets, and I used NPM to manage my packages locally. I had only started using Gulp in the past two weeks or so, but the tool had really grown on me since then, and I wanted to make it a part of my workflow moving forward.
I will be using Netlify CMS to have an easy UI to manage my blogs because I thought it looked like a coll project.
Project Structure
The project I am using actually uses the Gulp boilerplate from cferdinandi which makes it easy to setup the base files. Here is the project structure that I am working with:
- _posts/
- dist/
- src/
- copy/
- index.html
- js/
- sass/
- svg/
- gulpfile.js
- package.json
The project structure above is pretty self explanatory. The _posts folder is where all the written posts on my blog will go. We won’t be going into detail about this folder in this part, but I thought it a good idea to mention it here just the same.
The dist folder is where the compiled files go. This will be the production code of the website and this is what the web server will serve.
The src folder is where the source code of the entire website will be. This is the folder that Gulp will look into and and run the necessary tasks when we push to production.
The gulpfile.js file is Gulp configuration file that will have all the necessary functions to buld the entire website.
The package.json file is the npm configuration file that has all the developer dependencies so that someone else can clone the peoject and run it locally on their system.
Looking further into the src directory, we have the following directory structure:
- src/
- copy/
- index.html
- js/
- sass/
- svg/
The copy directory will contain all the files that we want to copy without any changes over to our dist directory. This will generally include static files that don’t need to be pre-processed like HTML files, pre-compiled vendor libraries like jQuery, BootStrap and so on.
The js directory will have all the JavaScript files that will be run through Gulp tasks to be compiled (or transpiled if we are using ES6).
The sass directory will contain all the Sass files and the partials for different Sass components.
The svg directory will contain all the SVG files exported from a program like Adobe Illustrator or Inkscape or even Figma. These files will then be run through a Gulp task that will optimise the SVGs so that it is ready for serving on a production build.
So there we have it! A neat project structure for our very own Gulp based CMS!
Setting Up Gulp
Before we leave, let’s setup Gulp so that we can start writing our function in the next part.
Remember, we will need Node.js to be installed on the development machine before we start.
Install Gulp CLI:
npm install --global gulp-cli
Now in order to install Gulp, let us do so by installing it as a developer dependency. In order to do that, we will need to create it in our project directory.
Let’s go ahead and create our project’s root directory. Please keep in mind that this is the directory that your server will be serving as the public folder to the network. On my Arch Linux install, I have set this to be ~/websites.
cd ~/websites && mkdir gulp-cms && cd "$_"
The above oneliner will first change the directory to ~/websites, and then create a directory called gulp-cms and cd to it.
Now we can run the command to initialise our project as a Node project so that we can use the Node Package Manager to install and manage packages.
npm init -y
Next, we can finally install Gulp in our project as a developer dependency!
npm install --save-dev gulp
And that’s it! You have now setup, and installed Gulp in your project. In the next part, we can start adding the Gulp functions and make the rest of our Gulp based CMS!