The re-birth of a website, a technical deep dive._

September 06, 2016 @16:00

I am hoping this will be the first of three or four posts detailing some of the technical bits under the covers of the new website. In this particular post I'll talk mostly about the design decisions that went into the whole infrastructure.

All of this works for me, and is based on my use-case. It is entirely possible that your application may be different and some of the decisions I made won't work for you, but at least you can hopefully understand the reasons behind it all.

So first, the givens

What I chose to do

Why

This allowed me to hand-create a single HTML template that gets applied virtually everywhere (the gallery has bespoke templates for it). I was able to craft a responsive design with almost zero JavaScript (only the mobile interface for the gallery uses JavaScript (jQuery)), which makes me happy. The site looks reasonable across desktops, phones, and tablets. It doesn't expose any data to any third-party sites. It is fast to load and render. It takes almost no server resources to serve.

Most of the pieces (which I will go into detail in the next few posts) have been around for a while but it is how I'm putting them together that makes it so much easier to maintain. I collapsed a lot of the templates down to a single base template class and only customize the bits needed to make each page. I also went from triggering this all out of cron(8) on the hour to building it when a change is pushed to the server. This not only saves server resources rebuilding things when nothing has changed, but also makes it so the errors are immediately noticed (in the git push output instead of in a cron mail that I may ignore).

Hopefully this makes sense. Next time I'll start talking about the oldest part of the site -- the template builder.

Subscribe via RSS. Send me a comment.