Reflection on Jamstack

After reading everything I’ve written in my last post, I’m surprised at how much I’ve actually had to do to make static sites work for me. It’s a lot when it’s all written down in one place (almost 3000 words!).

Jamstack.org has a bunch of great graphs and stats from surveys, and one that stood out to me is this one:

So many third-party dependencies that could be solved with one good CMS.

What was the point of Jamstack again? Is it scalability and flexibility? Or is it making startup founders money, while building website foundations on grains of sand, where the grains are all the third-party services you need to get functionality we’ve had for two decades?

It’s blunt, but it’s a feeling I’ve had for quite a while now about it, and why I try to keep my sites free of these third-party services as much as possible.

Not to say CMSs don’t suffer from this, too. WordPress for example, while a lot of functionality is built-in, you still need plugins for contact forms, spam control, image and CSS optimization. Some of these plugins literally are third-party services, just dropped in with a couple button clicks instead of code.

But, most of these plugins are easily replaceable. Contact forms. A different anti-spam service. Images stay in your CMS, so you can switch between any optimization service or CDN at will without breaking your site.

With Jamstack, I see lots of sites (not all) built around a few major third-party dependencies, with site-breaking consequences if they go down, and days/weeks of migration work. If you need a CMS, your entire codebase revolves around integrating it. Same with third-party image management. It’s not sustainable, unless you’re an org who rebuilds their site every couple of years anyway.

Here’s a bad meme I made, from Invincible, one of my favorite shows:

Even if you don’t rely on third-party services, you probably spend many hours fiddling with your templates, adding new elements and design changes, trying new things. This is both a blessing and a curse with static sites, your codebase is right in front of you at all times, and it’s so tempting to mess with things while you’re trying to write an article. And whoa, now things aren’t building, time to figure out why, oh man, that other SSG looks cooler, let’s switch.

Maybe it’s just me, maybe I’m spending too much time messing with my site setup, and I should try to pivot to another project and Just Leave It Alone™️.

Will I switch back to a CMS someday? Probably. Right now though, I’ve been on a writing streak lately, publishing a new article every other day, and almost every one has been my longest ever. So, my static site setup is working well for me, I’d say, but it took a lot of work to get here.

And I have a lot of people in my RSS reader whose static site works well for them too, judging by their posting frequency. At the end of the day, static sites are a tool, and it’s up to the wielder on how much duct tape goes on the handle.