I’ve wanted to start blogging for the longest time ever. Over the past few days, I finally got to it. This post won’t be much on my motivation for blogging, but rather the process I went through to finally get this blog up and running. As not much of a web designer/developer myself, I wanted to get my blog up with as little hassle (and cost) as possible. My intention in writing this is to help others like me expedite their own process.

What you’ll achieve at the end of this:

Pre-requisites:

Disclaimer: I was not paid to advertise for any of these services. Please do your own research before spending money on any service.

Step 0: Mimicry

Look for blogs in the same field that you’re looking to write in. Settle on a design that you like, then work to recreate it. Obviously, aim for a design that is within your ability to recreate.

Step 1: WordPress

At this point, I knew little about the world of blogging. But I knew one thing - WordPress. Touting itself as the backbone to 43% of the Web, it seemed like a good fit. Having used similar services before, like Wix, WordPress wasn’t too challenging to pick up. Its guided tutorials allowed me to settle on a design I was more or less pleased with.

I first settled on a site template, “Geologist - Slate”. It looked clean and minimally, not ugly. I got a decent looking blog up and running in a few hours. I then added a few posts and took my new blog “gerrardtai.wordpress.com” in. I’ve left it up for your reference. It was… nice, but not what I wanted. Here’s an evaluation that I came to.

Pros

[+] Easy to set up, hassle-free. Nice-looking out the box. This is pretty self-explanatory and expected out of most WYSIWYG site builders.

Cons

[-] Pricey. Wordpress has a free plan (that I was on), a starter plan (S$7/month) and a pro plan (S$21/month). The free plan had many things I took issue with, listed below. And there was no way I would be forking out S$7/month at this budding stage of my blogging journey.

[-] Watermark. The site has a huge banner across the top of the site (no matter where you scroll) and a “Made by Wordpress” at the bottom of the site. Not something I particularly fancied.

[-] Ads. While I run an ad-blocker, apparently the free plan of Wordpress places ads on your site. Once again, a big no for me.

[-] Cannot export site. Ideally, I would be able to export my Wordpress site to a bundle of html files easily, so that I could easily transfer hosts if I wanted to. However, there is no easy option to do so, and the only services I found that could export a Wordpress site as such were paid, or relied on Wordpress plugins (only available in the paid plans). Obviously, Wordpress would be losing profit if they enabled this feature, but this is another thing that turned me away.

[-] Clunky blog post editor. Admittedly, I didn’t see much use of this feature given my brief WordPress stint. However, from when I did use it, I felt that a. I wouldn’t want to write out my posts in that editor and b. Copying posts I had written on my computer over to the editor would be a hassle.

[-] No support for custom CSS/html. Under the free plan, you can only use WordPress’ simplistic block editor to edit the blocks that you drag and drop onto the site editor. The block editor had extremely few features, and any further customisations needed to be done via custom CSS. Unfortunately, this feature was locked behind the paid plans as well.

Evaluation

Overall, I felt that I lacked a lot of control over my blog if I were to use WordPress, so I decided to look elsewhere. Having said that, if I weren’t a broke student, I might well be using WordPress right now. The other main alternative to WordPress (at least, that I know of) is Medium. However, non-paying Medium readers have a monthly article limit, which is not something I can put up with.

Step 2 & 3: Jekyll & Design

At this point, my programmer brain kicked in. I realised I really only needed a static site (no dynamic content eg. a Node/Flask server running on the backend). From what I knew, and my experience with Heroku, I knew this could be achieved at no cost. However, there were a few hurdles I had to jump across first.

  1. WordPress’ site templating built a nice-looking blog for me with little hassle. Without using their services, I would have to recreate that design from scratch.
  2. WordPress was managing all my blog posts automatically for me. All new posts would be styled the same way, authors, tags and categories were also automatically sorted so that filters and searches would work.

WordPress isn’t sounding all that bad after all, huh? I knew that I would have to just bite the bullet for (1), and my plan for (2) was to create a markdown parser to generate HTML from. However, I had a feeling that building a solution for (2) from scratch would be reinventing the wheel. Searching online for existing solutions, I found Jekyll.

Jekyll

From this point on, the Jekyll Step by Step Tutorial was clear and sufficient. I first read through the entire 10 steps, then recreated the product alongside the 10 steps. Finally, I made my own edits to the code to create the site I wanted. The main differences I had were, namely, having 3 collections: category, subcategory, tag, instead of 1; a category navigation bar instead of a list of authors.

Design

At this point, I’ll address the elephant in the room - design. I’m not a web designer by any means, but my experience of mucking around in CSS over the years helped significantly here. With reference to my original WordPress site, I set out to recreate it. With the use of Flexbox (or a summary), simple padding-margin-border rules, and copious reference to the WordPress site, I had an almost replica of my original site.

Some design features were beyond my amateur CSS abilities, for example creating a dropdown menu within a Flexbox. At some point in the future, I will get around to adding in all the design elements I want, but the current design suffices for now. I think this acceptance is quite important, especially for people whose main goal is to start blogging. At some points, you need to ask yourself if the time investment in design is really worth it at this point.

Here are some CSS skills I would recommend having:

A really simple debugging trick to get the layout I wanted was to right click on the misplaced element -> inspect element -> check the box model’s margin, border, padding -> fix it accordingly with new CSS rules. Unless you plan on having a complex design, scrappy CSS will get you by for now.

Pzazz

With a more or less ready site, it’s time to add some pzazz to make your site stand out and be more memorable. It would also be a good idea to add some polishing touches. Here, I added:

Step 4: Hosting

The brunt of the heavy lifting is complete, and we’re left with two last steps. We have a server running on localhost, but we want other people outside our network to be able to access our site. This is where hosting comes in.

The option I was most familiar with is Github pages. The set-up was really quite straightforward. Provision a public repo, upload the static files to the repo, change the repo settings to serve a Github Page, voila! This was also what I was using for testing during the majority of steps 2 & 3. However, the issue I took with Github pages is that the repo had to be public (unless you had a paid, Github Pro account). This meant that anybody could easily download the repo and host a clone of my site. Additionally, any hidden content/easter eggs or yet-to-be-published posts would be open for all to see. So, I began looking for alternatives.

In the past, I had used Heroku to great extent. However, I had previously faced issues with Heroku’s free plan’s load-bearing ability, even on static sites. Since Heroku could also host dynamic sites, I thought using it for my currently static blog would be overkill. Looking at lists of free static site hosting services, I found Netlify, Amazon S3, Google Firebase, Gitbook. I eventually settled on Netlify which was very straightforward to use. I signed up with my Github account, linked the repo for my blog and the site was up and running! I proceeded to privatise my Github repo.

Step 5: Custom domain

In this last step, we’ll replace the name Netlify provides automatically with a custom domain - one without “netlify” or “github” etc in it. This is the only step thus far that will cost money.

Of course, if you do not wish to use a custom domain, you can use the domain netlify, firebase, github, heroku provide for free. You can customise the subdomain (as long as nobody else is using the same name), but the domain name will remain that of whichever service you use - “customisable.netlify.com”.

To purchase a custom domain, you need to go through a domain name registrar, like GoDaddy, NameCheap or Domain.com. Look through a list of registrars online, look for the domain name you want and compare prices. Take into account available discount codes and also chargable add-ons. For example, GoDaddy and Domain.com have a paid private domain registration feature, whereas it comes for free with NameCheap (I would recommend getting this feature). In the end, I settled on a NameCheap, which was the cheapest option (~S$8). Then, it is simply a matter of aligning the NameCheap DNS records with that of Netlify. This is a good reference to do so, and here is one for Github Pages.

It may take a while for the DNS records to propagate, so go and grab a coffee first.

Learning points

If you’ve reached here, you should have your blog online for all to see. Congratulations!

If I were to set up a blog again, I would use TeleportHQ (or alternatives) to help design my site as it can export to HTML, instead of using WordPress as essentially a prototyping tool. I would also try using a dynamic site instead (Amazon S3 and Netlify can house a dynamic app for free too) to allow comments, forms etc. I would probably still go with NameCheap and Netlify, because the process of using them was entirely seamless.