Hello, and welcome back once again to Front End Center!
I’ve spent the last few weeks transferring over the client sites I host from an older server, to a newer one with better speed and security. In the process, I was reminded of the potential hazards of development complexities that can sneak into the most basic of sites. While leveraging Wordpress can make some problems trivial, it’s also got equal tradeoffs and stress points that show up at the least opportune moments.
I’d left Front End Center for last, to give myself time to consider various alternatives for audio hosting, playback, and RSS generation. While the rest of that list is still cooking, I did decide to leverage a new tool while transferring between servers.
Unlike many of the client sites, I decided to code Front End Center’s site in bespoke code, rather than rely on a content management system. I’m the only one who has to worry about uploading content and adding pages, so the extra layer of complexity was something I gladly skipped.
As the site has grown, though, each week’s episode added additional considerations. First, make sure to move the oldest episode down the page. Is it an interval of five? Time to start a new page and amend links between them! So on and so forth.
No, I’m not completely crazy, I knew that would eventually happen. Yes, I did it on purpose. There’s a perverse sort of pleasure to be had in doing mundane, direct code work once a week, instead of worrying about how a given line of generalized CSS will scale up and effect multiple platforms of enterprise solutions.
For all that, there does come a time when a little bit of automation and process is appreciated.
Enter: Static Site Generators.
For those who aren’t already familiar with the topic, let’s start at square one. Static Site Generators have been growing in popularity for the last two or three years, but are far from a brand new idea. In fact, the whole goal of their end product goes back to the root of simple, old-fashioned web design.
Many sites today are dynamic, rather than static. Wordpress provides a great example many will be familiar with. Instead of writing each page by hand, again and again, a dynamic site puts together the page content at request. Your server finds and assembles your head file, your footer file, the content stuck between them, and sometimes much more.
While this is all super convenient for making big sites (who wants to update a navigation link 50 SEPARATE TIMES whenever there’s a small change), it does place some stress on your site. Because there’s more work to do than just displaying a pre-written page, user load times will increase and there are more moving parts to break. A common nightmare scenario would be too many users making page requests at once, and overloading the server. Now no one can request any pages at all, because the page-builder behind the curtain ran screaming out of the server room.
Static Site Generators acknowledge the benefits of dynamic site building, but reframe the process as a question “When?”
Rather than force servers and browser to take the brunt of assembling pages each and every time they’re requested, why don’t we do that process a single time, on the developer’s machine?
A Static Site Generator is a process, often powered through our favorite word-salad tools (Ruby, Node, Grunt, Gulp, and more!), that happens before the code ever sees a live web server. When you save your header.html file in your text editor, the Generator takes notice and springs into action.
With the new code in hand, it flips through the other pages, posts, and content in the designated folder and sees what files will be impacted by the updated header file. It then recompiles those files with the new header code, saving you endless amounts of manual repetition.
There are issues that mean Static Site Generators aren’t for every person or every project. They can be tricky for client work that you expect to hand off to non-technical maintainers.
Some Static Site Generators have popped up that attempt to handle that problem by either making specific tasks (like blog posting) accessible without technical skill, or adding in a localized mini-CMS to mimic functions like Wordpress posts.
While the efforts are valiant and steadily improving, many of them still require very deliberate and often complex advance preparation. Trading Wordpress for a desktop install of XAMPP does not a happy business-owner make.
Another issue is that, for all its faults, dynamic content has some unique benefits over static content. Want to know what the most popular article on your site is AND have it automatically show up on the home page without your intervention? That’s dynamic.
A static page is just that: static. If you want to feature a new article in real time based on user views… you’re going to be sitting there yourself and amending the page constantly.
Both of these methods of development have their place and unique conveniences in the modern web. Being able to pick the appropriate tool is part of the challenge of working in the field. I’ll be enjoying updating the Front End Center site via a Static Generator, while still leveraging completely hand-written code and many different dynamic solutions elsewhere.
No one said having more choices was an easy thing!
I’m still running the podcast questionnaire that can be found in the episode description or on http://fec.fyi. It’s a very short set of questions, focused on the content and quality of the podcast, and what I can do to improve the experience! I greatly appreciate everyone who takes the time to fill it out.
Until next week, thanks for listening! This has been Chris Landtiser, and Front End Center.