Skip to main content

Building My Site, Part 2: Methods and Tools

Posted on: 09/06/2017 · Estimated reading time: 8 minutes to read

Welcome to the second of a series of articles in which I explain how I designed and built this site and why I made the choices I did.

It’s going to get a bit technical, but while I’ll try to explain everything in the plainest possible English, some grounding in web design and development would be useful. Rather than cover the basics, I recommend spending some time in the “Learn Web Development” section of the Mozilla Developer Network.

Some exposure to Unix/Linux and shell scripting might also be useful. If you aren’t familiar, try linuxcommand.org.

While subsequent articles will explain the internals of this site in detail using source code listings. You can also access all of the code for my website on GitHub.

You can read previous installments below.

Methods to the Madness

After deciding what I wanted my website to accomplish and how I wanted it to work, I had to decide how I would go about building my website and what tools I would use. I’ll cover tools later, but first I want to discuss five general approaches to building a website.

  • Building a Static Website Entirely by Hand
  • Be a Digital Sharecropper
  • Rent Access and Space on Somebody Else’s CMS
  • Install, Customize, and Maintain a Content Management System
  • Write Your Own CMS
  • Using a Static Site Generator

I’d say these approaches are ranked in order of how badly they suck, with the worst at the top, but all of these options suck for different reasons. I’m just putting “Using a Static Site Generator” last because it’s the one I chose.

Building a Static Website Entirely by Hand

The first approach is how we used to do things. You build every page by hand, writing the content as raw HTML, and linking pages together manually. Then you upload the whole thing to a web host.

This approach still has a couple of advantages:

  • You can be as creative as you like.
  • Every page can be unique.
  • You have complete control over markup and style.
  • Static pages are incredibly lightweight, and cost next to nothing to serve in terms of server resources and bandwidth.

However, this approach also has a few severe downsides.

  • Side-wide changes require manual editing of every file.
  • It doesn’t scale beyond a few hand-crafted pages.
  • Doing everything yourself takes a lot of time.
  • Writing content in raw HTML is painful.

I used to do this. I’ll go back to scrubbing toilets for a living before I ever do this again.

Be a Digital Sharecropper

This is what most people do these days, and the world wide web is worse for it.

If you create a free account on platforms like Blogger, WordPress.com, Tumblr, or Medium and use that as your primary web presence, then congratulations. You are a digital sharecropper. Why is this bad? I’ll give the explanation its own paragraph and make it bold.

You’re busting your hump to make somebody else’s platform more valuable, and you aren’t even getting a paycheck out of it.

If you post original content on Google+, Facebook, Twitter, etc, you’re also a digital sharecropper.

There’s only one advantage to this approach:

  • It requires minimal technical knowledge and investment on the part of the author, because the platform is a web application managed by a team of professional technicians.

The downsides are legion. Here’s a short list.

  • You don’t own your content.
  • You can be kicked off for any reason, or none at all.
  • You have no control over your content’s presentation.
  • You probably don’t get to use your own domain name.
  • Who you reach, and whether you reach anybody at all, is out of your control
  • The platform’s owners will use ads to monetize your content, and you won’t get a cent.

You should not post original content on platforms you don’t own unless you are a paying customer. The more often you do so, the more of a sucker you are.

This isn’t an option for me, and I feel so strongly about this that the only social networking account I still have is Google+, and I only use that to share posts from this site and to interact with old acquaintances.

Oh, and there’s my Medium account, but that particular content farm is a subject for another rant.

Let’s just say that if Ev Williams wants me to click “Write a Story” instead of “Import a Story”, he can damn well put me on his payroll as a staff writer;—which will probably happen the first Tuesday after Ragnarok.

Rent Access and Space on Somebody Else’s CMS

What’s the difference between a free WordPress.com blog and going with WordPress.com’s “Personal” plan at $4/month?

  • You’re a paying customer
  • You get to use your own domain name
  • You’re entitled to technical support from WordPress
  • Twice as much storage space
  • No ads from WordPress making your work look tacky

Paying for service has all of the advantages of being a digital sharecropper and building your web presence on somebody else’s platform “for free”, without most of the downsides. If you’re a paying WordPress.com customer, you can still get kicked off if you violate their terms of service, so make sure you read and conform to them.

Install, Customize, and Maintain a Content Management System

Some content management systems (CMS) like the aforementioned WordPress aren’t just services; they’re also open-source software packages that you can install on a server or virtual machine of your own, on a virtual machine you’re renting from a hosting provider, or on shared hosting.

It’s not without advantages.

  • Unless you’re a royal pain in the ass, your hosting provider probably won’t give you the boot as long as you pay on time.
  • Your customization options are limited only by your knowledge and design/coding skills.
  • You can expand your CMS’ functionality with any plugins you like.

This option also has some severe downsides.

  • Keeping your CMS current with the latest bug-fixes and security patches is your job.
  • Your CMS uses a database, which you must also keep current.
  • It’s more expensive to host a CMS because of the additional server resources required. A CMS rebuilds pages every time they’re requested unless you set up caching, which is slow and costly.
  • WordPress in particular proves that not only can just about any random idiot code in PHP, but a great many of them do. It’s a big-ridden piece of shit, and running it is a great way to get your site cracked.

Write Your Own CMS

This is out of the question. I might have the programming chops, but I only reinvent the wheel when I’m getting paid to do so.

Using a Static Site Generator

Now we’re talking. A static site generator is software you run on your local computer to convert templates and content files into a complete website made of nothing but static HTML files and any stylesheets, image assets, multimedia, and client-side code you care to layer on top.

Here are the advantages as I understand them:

  • You only build the site and upload it when you’ve made changes.
  • Because everything is rendered, pages get served much faster and with less resource usage.
  • Because resource use per page is low, a static site can handle more traffic and is more resistant to distributed denial of service (DDOS) attacks.
  • You have full control over your site’s structure and appearance.
  • You can put your entire website under source control using tools like git.

I don’t mind the disadvantages, but you should be aware of them.

  • Most static site generators are made by programmers for programmers.
  • Most static site generators are command-line tools.
  • Most static site generators target Linux and Unix; Windows support is an afterthought.
  • If you want comments or other user-generated on blog posts, you need third-party add-ons.
  • If you’re a perfectionist, you might spend more time tinkering than writing.
  • You you must at least be familiar with HTML, Sass, CSS, Markdown, YAML, and JavaScript to make effective use of static site generators.

A Choice of Tools

Given the choices above, I choose to stick with static websites. The question is how to go about it? The first step is to decide what tools I’ll use to build my site.

Jekyll is the obvious choice due to its popularity and integration into GitHub. Hell, if I didn’t mind the limitations involved I could host my site for free on Github Pages. Since I’m familiar with Jekyll and have already built the site, I figure I’ll stick with it. :)

If you’re starting from scratch, you don’t have to use Jekyll just because I do. You could also use tools like Hugo, Pelican, Middleman, Metalsmith or even Gatsby—but I don’t recommend Gatsby unless you like dicking around with React.

However, Jekyll alone isn’t enough. It can’t compress or resize images for me. For that I need tools like ImageMagick and jpegoptim. I need git for version control, rsync for deployment, and shell scripts to link everything together. And if I want to have my site automatically built and deployed when I commit changes and push them to Github, I need a continuous integration service like Travis CI.

It’s pretty complicated, but I’ll explain everything in future posts.

Additional Resources

Here are some more articles explaining the advantages and disadvantages of going static, with an emphasis on Jekyll.

Next Post…

In Building My Site, Part 3, I’ll discuss my Jekyll setup.