kaidez 2017 site redesign

I lost my WordPress blog because I deleted the database by mistake. So I had to rebuild it quickly to keep from losing the little “link juice” I have.

My day job’s kept me busy, making me work some late nights and (sometimes) on the weekend. Consequently, I haven’t had time to document this 2017 rebuilding process until now: when 2017 is almost over.

Table of Contents

  1. Developing with the K.I.S.S. Method
  2. Jekyll...Again
  3. Free Hosting with GitHub Pages
  4. Site Speed is "Fine", But Not "Perfect"
  5. Practicing With the Rest
  6. Conclusion

Developing with the K.I.S.S. Method

This was, above all, the core foundation of my web development process for this redesign. K.I.S.S., or “Keep It Simple, Stupid.”

I’m fortunate to have worked for a variety of great companies over the course of my career. From this variety, I’ve learned that I work best on teams that prefer simplicity in web development over trend-chasing.

This is not to say I don’t try and learn new, complicated stuff: I do that at night. But while on the job, I prefer web dev tools and techniques that help me get the job done fast instead of the ones trending on Twitter at the time.

Hence, this is how I approached rebuilding my blog: just using the tools I needed to get things done. I didn’t want to do complex coding things just so I could say “I did complex coding things.”

Jekyll...Again

For my 2013 site redesign, I left WordPress for the Jekyll static site generator because I wanted to try Jekyll. For my 2015 site redesign, I went back to WordPress so I could use its rich ecosystem of plugins for managing things like SEO and 301 redirects.

But as mentioned, I had to get this 2017 version up ASAP, and using Jekyll was faster than using WordPress. And I have to say that Jekyll has really really improved since the last time I used it.

First of all, Jekyll builds out the entire site fast…faster than the last time I used it! It also now has great Sass integration, with Sass being my preferred CSS preprocessor.

But what’s REALLY impressive is how much Jekyll’s plugins ecosystem has grown since I used it last. It has plugins for gallery creation, Twitter card conversion, tag building, etc.

My blog uses four plugins:

  1. Jekyll SEO Tag: lets you add Open Graph configs, canonical URLs, JSON-LD configs and other SEO stuff to your Jekyll site
  2. JekyllRedirectFrom: configure 301 redirects for single page or post.
  3. Jekyll Sitemap Generator Plugin: create a sitemaps.org compliant sitemap for your Jekyll site.
  4. Jekyll::Paginate: Jekyll's default pagination plugin...no longer under development so I'll ~probably~ to get rid of it eventually.

These are mostly based around SEO but I may take a peek at the other Jekyll plugins. But in general, mad props to the Jekyll community for making it easy to extend Jekyll overall.

Free Hosting with GitHub Pages

In terms site hosting, I was a loyal Media Temple customer for almost a decade. But because I had to get my site back up fast, I had to go with GitHub Pages.

This way was faster because 1) Jekyll has awesome GitHub Pages integration, and 2) I already have a GitHub account. As a result, rebuilding most of my blog and deploying it to a production-ready host took me all of three minutes…updating my blogs’s DNS settings took longer.

This speed and ease cascades down to my workflow. First, I do my updates on a development branch that runs on Jekyll’s local web server, making things browser-accessible.

When things are ready to go live, I merge the dev branch into the master branch on GitHub. This automatically pushes the updates to the live blog.

Furthermore, hosting on GitHub Pages is free, saving me almost $400USD a year in hosting fees!

Site Speed is "Fine", But Not "Perfect"

Again, Jekyll is a static site generator. Meaning that each page on my site is an HTML file instead of being dynamically created from a back-end database.

So the site loads pretty fast as a result, but GitHub Pages is shared hosting…powerful shared hosting but shared hosting nonetheless. As as result, there are some things I can’t do to make the site faster:

  • No server config files allowed: GitHub Pages doesn't let you use of things .htaccess, web.config or nginx.conf files. So I can't implement good file caching and apply far-future expiration dates to images, JavaScript files, CSS files, etc.
  • No CDN: my previous site used MaxCDN (now called StackPath) to serve static assets...GitHub Pages seems to block MaxCDN.
  • Can't use HTTP/2: if there was one thing that would've made me walk away from GitHub Pages, it was this. I was really pumped to use the newer, faster, easy-to-use HTTP/2 protocol but GH Pages doesn't allow it. And since, I'm using a custom domain name, GH Pages won't even let me do HTTPS.

With the exception of HTTP/2, these things have led to low scores on WebPagetest, Pingdom and PageSpeed Insights. But I’m really not worried about that: the site content is static, making the site as a whole fast enough.

Still, the “no-HTTP/2-or HTTPS” thing kind of bugs me. That MIGHT make we walk away from GitHub Pages sooner than later…just being honest here.

(Note: Rebecca Murphey has an excellent post about HTTP/2 if you’re unfamiliar with it.)

Practicing With the Rest

While I did use more complex JavaScript-based tools and techniques, I didn’t use them too extensively. I just used them to get more familiar with them.

Those tools were:

  1. BEM CSS: I've been focused on implementing more component-based CSS design patterns in my work. The one I love most is BEM (Block Element Modifier). It pretty much follows the OOCSS way of doing things but with a stricter naming convention: It's a de facto industry standard now so I implemented it for practice.
  2. React: Also for practice, I created two React components: the menu and the footer. Very basic: no Redux or selector patterns or anything like that...just practicing React.
  3. webpack: I was completely fine using Browserify for modularizing JS files but webpack, like BEM, has also evolved into web standard.
  4. Yarn: Same thing here: I was completely fine using npm as my core package manager, but everyone prefers Yarn now. To be fair: Yarn is faster and did some things better than npm in terms of caching. Also, to be fair, npm has since improved itself in terms of speed.

From a JavaScript, there really isn’t much to to talk about on this new site. To paraphrase @fat, I wanted to write some JavaScript and forget about it.

(Note: in the article linked above, @fat does talk about starting off with simple JS in his work, then complicating it with React. So I am being a bit contradictory by pointing to that article while talking about simplifying my own JS, but I’m OK with that right now.)

Conclusion

My previous site update posts were much more grander than this, but I’m really about simplicity in code right now. Particularly when it comes to tooling.

Feel free to check out the blog’s codebase on GitHub: you may like the React stuff. But things are pretty simple overall, and I’m A-OK with this.

Would you like to Tweet this page?