My history with blogging goes back pretty far. How far? This was before Google Chrome, before the iPhone, before Twitter and Instagram. I first launched my blog nearly twenty years ago - in February of 2003.
At that time, I was heavily involved in the ColdFusion. I built my own blog in that language and shared it with the community. I named it - BlogCFC (yes, not terribly creative) and carefully groomed into it a pretty decent blogging platform for nearly a decade.
Building my own blog software from the ground up was fun and let me tailor to my specific needs. Growing it into an open source project that was used by hundreds of users was also pretty cool. But after ten or so years I was ready for something new.
WordPress for Blogging
I decided to make the switch from a custom blogware running on an ISP offering ColdFusion hosting to a Google Cloud machine running my own install of WordPress.
Like many developers, I was well aware of WordPress. I had not had much, if any, experience with it, nor was I terribly familiar with PHP as well, but the initial setup experience wasn’t too difficult. Migrating my older content from one database to another was a bit harrowing, but eventually I had my old content up and running just fine in a shiny new WordPress install.
Everything was Perfect with WordPress
If you’ve only heard of CMS WordPress but never actually used it, then you truly do not know how incredibly well done the platform is. As a developer, I don’t mind it when things are simple and WordPress made the authoring process incredibly simple and pleasant.
This was nearly ten years ago and I’d imagine the experience has only gotten better. After I had my theme and content up, writing content was a perfect experience.
Until…
Error establishing a database connection
If you’ve been on the internet for a while, you’ve probably seen this error before. With the prevalence of WordPress sites (over 40% of all websites) it’s not uncommon to run across an instance that’s having a bit of trouble, especially if it’s being hammered with traffic. I think I had my WordPress site setup for less than a week before I hit this.
Now, I want to be clear, as much as I love my blog, and writing, I did not spend a lot of time actually researching the best way to use it. This may come as a shock to you, but sometimes, some developers just wing it. That’s what I did. I both cared a lot about my blog and also didn’t want to actually think a lot about the actual maintenance and servers and so forth. I just wanted to write.
My blog gets what I’d call decent traffic, at the time maybe 500k page views per month, but nothing I’d consider extreme. I discovered that (at the time), certain performance optimizations were not enabled by default. So, no big whoop, I added as much caching as I could and…
WordPress failed again
So at this point, I started digging into my Google Cloud settings, PHP settings, web server settings, and more. I’m a developer, I like that, but again, I just kinda wanted things to work. I eventually got things to a somewhat stable state, but I never lost that slight apprehension that something was going to go wrong, and probably at 2AM my time.
Static Site Generators
Fast forward about two years (2016) and I determined I was ready for something new. At this point, we were a few years into the introduction of static site generators (SSGs). While they have an older history (Jekyll, for example, came out in 2008) the idea of “going static” had slowly been growing in popularity.
What is a SSG?
At the simplest level, a SSG lets you have the power of an application server in your local environment. You can create files and point them to a layout template, ensuring you have a consistent look and feel across your site. You could work with data and use it within your site. But here comes the sweet point - to go into production, you run one command and the SSG converts everything into simple HTML (and CSS, JS, images, etc.)
SSG Architecture
I had been using application servers for nearly twenty years at this point and I was fascinated by this. All of a sudden my production environment goes from:
Web Server
Application Server
Database Server
To:
Web Server
In my mind SSG Architecture means a dramatic reduction in the number of things that could go wrong.
It also expanded the opportunities for hosting. Now I didn’t care if the host supported ColdFusion, or PHP, or anything. All I needed was the ability to server up web resources.
Formspree Contact Form
At the time, the biggest issue with SSGs was adding back in things that necessarily needed to be dynamic. The simplest example of this is form processing. Trivial in an app server, but impossible in a site that’s just serving files.
Luckily a large number of third party services sprang up. For example, Formspree let you create forms that POST to their service:
<form action="https://formspree.io/f/{form_id}" method="post">
<p>
<label for="email">Your Email</label>
<input name="Email" id="email" type="email">
</p>
<p>
<label for="comments">Your Comments</label>
<textarea name="comments" id="comments"></textarea>
</p>
<button type="submit">Submit</button>
</form><form action="https://formspree.io/f/{form_id}" method="post">
<p>
<label for="email">Your Email </label>
<input name="Email" id="email" type="email">
</p>
<p>
<label for="comments">Your Comments </label>
<textarea name="comments" id="comments"></textarea>
</p>
<button type="submit">Submit</button>
</form>Formspree lets you define form instances, gives you a unique URL, and you can then simply use that in your action field. Formspree can do spam checking, integrate with other services like Zapier, and then simply redirect the user back to your site. Typically, your site’s users will have no idea any of this happened.
This explosion of services made the static sites idea even more appealing. More and more, static sites were being enhanced with thirty party APIs to the point where it felt like you could do nearly anything with them that you could with a “traditional” app server. With serverless this became even more true as it allowed you to truly build customized APIs that exactly meet your site’s needs.
At the time, I was presenting (and writing) about this topic quite a bit, and I found myself saying over and over, “It’s static but…” Other people realized this too and recognized that as a name, “static sites” wasn’t cutting it.
Jamstack: The Next Step
In 2015, the term “Jamstack” was coined by two founders of Netlify to help redefine this rapidly changing ecosystem. First used as “JAMStack” with the J, A, and M representing JavaScript using APIs tied to Markup,
Jamstack now refers to the architecture that employs the early promise of static site generators with APIs and performant hosting to provide better security and performance.
Jamstack vs WordPress: Migration
With some experience in static site generators, I took my first steps into the Jamstack world by looking at a few older sites I had running. I had more than one site using ColdFusion and a database that had not had a change to their content in years.
I was lucky to be running these sites for free (many of my sites were for the ColdFusion community, so I typically did not have a problem finding an ISP to host them) so they weren’t costing me anything, but I realized that I could turn them static, deploy the files, and then… just leave them be.
At the time I wasn’t even concerned about further updates (more on that in a minute), so the conversion made sense. I did this once or twice and quickly became addicted to the idea of worrying less. (Imagine that.)
Is Jamstack better than WordPress?
While this was easy enough for small websites, I was a bit hesitant to make the move on my own blog. I finally took the plunge in 2016 (“Welcome to RaymondCamden.com 2016”). The process was a bit intense (you can read more about it here), but basically boiled down to:
Exporting my content from WordPress (pretty trivial)
Learning Hugo
Writing a script to migrate WordPress content into Markdown templates
Jamstack vs WordPress: The Difference
And here’s where the biggest difference came in. The WordPress authoring system is… perfect. Honestly, I can’t imagine a better system for bloggers.
For the Jamstack (at least initially), the writing process means opening a file in your editor, writing your content, and then saving and redeploying your site.
This is much simplified by hosting services which can integrate with your source control and handle automatically building when you commit code. I’ve also built my own scripts with the main purpose of - “I have an idea and get to the point of writing as fast as possible.” But as you can tell, it’s definitely more of a manual process.
What makes this appealing to me however is that this manual process is on my local machine. I’m comfortable working there, comfortable breaking things there, and generally don’t mind it. Working with a large site (I’m currently hosting over six thousand blog posts) means I’ve got a complex set up, but again, that complexity is - for the most part - local to my machine.
Jamstack CMS
In general, my writing process now is:
Run a script in my terminal to create a new post file
Open the file in my editor
Write awesome content!
Commit to GitHub
Everything else is then automated
I should point out that as the Jamstack ecosystem has evolved, so have the services around it, and there’s absolutely WordPress-like CMS systems that integrate well - see the CMS resources at jamstack.org, a good resource in general.
Conclusion
While static sites have been around since the beginning of the web, the Jamstack as an architecture has truly exploded over the past few years. As with any new idea in tech, there’s going to be quite a lot of hype surrounding it. It’s totally fair (and completely accurate) to point out that the Jamstack is not the best solution for everyone. If I’ve learned anything in my time in tech, having options is almost always a good thing, and going forward, I see the Jamstack as an appealing solution for many, if not all, developers and projects.
