What This Site Runs On – Part 1


Having gained a lot of new front-end skills with my newish job at Staplegun, I decided to give my site a revamp. The old site was a pretty minimal (ahem…terrible) landing page that just gave basic information about myself, as well as external links to some of my projects. Now, I felt like I could finally develop a site that houses more than just external links – so I decided to rebuild it all. I’m pretty happy with it, and I thought I’d share the tools, languages, and frameworks I used to build everything

Where does the name The Societea come from? We’ll save that for another post.

I’m breaking this topic up into 2 posts; this one will specifically deal with my choice on whether I decided to use a database for my site, and furthermore, a CMS. Let’s get to it:

My Initial Planning

I initially planned to revamp my site into a completely static project that was just straight HTML, CSS, and JS. I was planning to have a static page blog where each blog post would be its own Markdown file, and then to use a server-side build tool like Middleman to use ERB and build/rebuild out the pages after each blog post. I would use nginx to load the pages super fast, and most importantly, I would only need a simple Git repo to manage the entire site; no database whatsoever.

But, then I started wanting to take it further. What if I wanted to tag my blog posts, and maybe even give some dynamic options on the page to filter blog posts based on tags? I also wanted to show off my projects that I’ve worked on as well and give them sortable tags as well (languages used, role, company, etc.). Could I make the projects modular code-wise on the site, and split them up into template-like blocks so I didn’t have to code the exact same html multiple times? Would it be difficult managing posts, projects, and other repeatable chunks? The more I got down to it, the more I felt like I needed to get a database involved.

How It’s Implemented

Based on my needs, I ended up using a database. I ended up using a CMS. Yes, I ended up using WordPress. I’m using WordPress, and it’s exactly what I needed. Through a CMS I’m able to handle code chunks incredibly easy with posts, projects, and more, and updating anything is so simple. I coded my projects page initially sans-CMS, and I was looking at over 150 lines easily since I was duplicating so much html. Now, by pulling my images and text from a database, that’s down to 43 lines (including whitespace lines) — and I’m using the same template for my blog posts parent page!

Now I know CMSs aren’t the cool things developer-wise anymore, but I’ve come to realize what they are. A tool – nothing more. As a developer, I’ve gone through 3 phases of WordPress acceptance:

Phase 1 – What’s WordPress? *is shown WordPress* …. Wow, this is awesome! I can make a decent looking site in no time with free themes and plugins!!

Phase 2 – WordPress? Nah, that’s not cool once you’re a real web developer. Custom build all the things!

Phase 3 – I know what I need. I know what WordPress does. WordPress is what I need to organize my site and manage the things I need to manage. I’ll custom build the site structure and styles myself.

So, yes, this site runs on WordPress, and I’m loving it. I custom built the theme and have all the visual plugins running purely through javascript, so I’m literally using a CMS just to manage the content that actually needs managing. Not everything though, mostly just repeatable things.

Cons of Using a CMS

There are some things that were very important to me that I can’t reap the benefits of anymore due to using a CMS:

Slower Page Loads – Since the site now interacts with a database, it’s certainly not faster than purely static pages being served up by nginx. Though I really can’t tell much, I still know that’s a fact.

Version Control Complexity – Having a database complicates code management. I initially wanted to just be able to push my files up to a Git repo, clone it anywhere, and know it will just run as is. However, now I need to dump the DB into a local dump SQL file, put that in the repo, and then restore the DB based on the dump file. And, if it’s an initial clone at a new location, I’ll also need to create the DB user and the actual database itself. It’s not too much extra work, but it’s more complicated than just a ‘git clone xxx’.

So there you have it. My site uses a CMS, and while there are some cons associated with that, I chose to use one because the benefits outweigh the negatives by a longshot. I know I didn’t cover much here, but I really wanted to explain my rationale and some of the struggles I was…well…struggling with as I was planning this site.

Next post will cover specific tools I used to build the site, js plugins, preprocessors, and page optimization. Stay tuned!