Static Cling

While spending time generating the basics of my recipe site (which will likely move soon - I'll update the address once the move is complete), I've been on the hunt for software engineering tools that will make its maintenance much easier.  As the site stands now, it's fashioned in a 1997 type of HTML and CSS only site that requires a lot of duplication.  For every recipe I create, I need to copy an old page, make the necessary updates to the page for the new recipe, proofread it to ensure I don't have any typos on the page, deploy it and view it to ensure it renders correctly to the user.

This is really error prone, especially with 52 recipes.  It also makes updates to the site extremely difficult, because if I want to, for example, switch the ingredients section with the instructions section, I have to make changes to 52 pages.

As any competent software engineer knows, we don't want to do this.  We want to follow the DRY principle (Don't Repeat Yourself).  The layout for the recipe pages is exactly the same.  The only thing that differs is the content.  So, if I can create a template for the page and render the content, I give myself a lot of flexibility and freedom from maintenance nightmares.  Turns out it's 2018, and this has been the core of web programming for the better part of a decade and a half. 

My preferred requirement is to keep the site static.  That means that once a user makes an initial call to the website, there are essentially no further updates required.  There's no data storage on the backend that the user needs to interact with, no middleware to call, no philosophies for caching data for speed, since the content has already been generated and isn't going to change.  By and large, a static website is not what the vast majority of the websites in the world are.  If you're running a travel website, for example, you'll need to call back to other systems to log users in, search flights and hotels, remember their preferences, and process their payments.

However, with a recipe website, where the content changes infrequently, we don't need to log users in (unless I begin offering premium content or sensitive content), and we don't need to process payments, a static website is preferable.  It's less maintenance, and, since it has fewer moving parts, more secure, both from my perspective and the user's.

So, then - a static website with some seemingly dynamic content.  Sounds like a job for Javascript!  I won't go into the details of how I selected a framework, but I eventually selected Vue.js for the job.  It's got a clean interface and would be able to help me follow the DRY principle.  Except that it also adds a lot of overhead to the site.  I'd need to install something called vue-router to make sure that I could create recipe content on the fly.  In order to use vue-router in a manner that makes it easy to read and write, I'd need to install a Javascript bundler called webpack. In order to use webpack, I need npm.  In order to make sure the Node version associated with npm was up-to-date, I'd need nvm.

So, then - a static website with some seemingly dynamic content.  Well, there's a much cleaner alternative that I'd only heard in passing - a static site generator.  The industry standard seems to be Jekyll.  It took me a little while to get into the groove, but the documentation is pretty solid and there's a ton of additional help online, which is great.  Unlike Javascript, which injects content into a template when a user requests a particular recipe, the site generator uses the template before I even post the content to create a bunch of seemingly duplicate pages.  From the user's standpoint, it looks like I am just creating tedious HTML and CSS pages, but from my standpoint, it's all done with a little code and is as easy, if not easier to maintain, than a Javascript based solution.