My Experiences Jammin' The Stack
Tags: webdev, programming
Published: 2021-03-11 01:30:22

> This is an open letter to the JAMStack community about my experiences with the technologies so far. What I love, and more importantly what I don't love about the experience. While I am likely to be critical here I don't know how else to share this in long form. If you've come across this on social media and have any thoughts please share them as I'd love to iterate on what I have experienced already.

## Stop trying to put jam in there...
There are a number of things in this world I want to love. Either because I just think they are cool or because I think they fit the vision that I have of myself. Whenever I can't enjoy one of these things, particularly the ones that deviate from my own internal picture of myself, it makes me question if I really know what drives me. There are a number of these such things but a few that I keep trying and failing to fall in love with are:

- Linux as a full time OS
- Drawing
- Being super into a franchise
- Making physical things _(with my soft hands that always get hurt because I only require enough dexterity to hit these keys in roughly the right order every day)_

And lately I've been able to add the JAMStack to that list.

## What is a JAMStack?
In case you have stumbled across this post and wonder why anyone would want to put jam anywhere near their tech stack let's get out of the way what this acronym is all about. JAMStack stands for a stack made up of Javascript, API's and Markup. Strictly speaking this typically means applications that have been developed by static site generators (or similar) that can be served out of a file storage location such as [Amazon's S3](https://aws.amazon.com/s3/).

The proposed benefits of the JAMStack are:

- Better Performance
- Higher Security
- Cheaper, Easier Scaling
- Better Development Experience


For more information I'd visit [jamstack.org](https://jamstack.org/).

## Is it really better?
I completely agree with the notion that serving static files from a Content Delivery Network (CDN) makes for better end user performance and provides a much cheaper way to scale website throughput.

I can even get behind the notion that the site is more secure, although I still firmly believe you can misconfigure anything. I wouldn't be using this solely for its security benefits and rather consider it as a defense-in-depth mechanism along with your other tooling and build processes.

What I am struggling to get behind in practice is the Better Development Experience. Naturally everyone creates content differently and for different reasons. I chose to create my own little corner of the internet and create blog content outside of the larger centralized blogging platforms. I risk a smaller reader base but I get to grow something that is my own and enjoy writing about things that make me happy and not necessary to watch the stats in my admin panel get better.

Because of that my experience running my website now is largely about content creation. While I can (and definitely will) re-do this site again at some point, the design is purely driven by intrinsic motivation and a need to spice things up. What is most important to me is being able to jump into my browser and create blog content either on a whim, when motivation strikes, or as a planned endeavour (like today). Despite there being tooling out there to fit this exact purpose I've had a really hard time adopting the JAMStack when all I want to do is regularly author content.

---

The following experiences aren't going to be presented in any sort of chronological or hierarchical format. They are just different things, that as the sum of their parts, put me off of JAMStack given my current workflow. I would love advice on how this could be changed, if for nothing more than my adding to my "not for me" list.

## Markdown is fine, I guess.
Markdown is great. Let me just get that out of the way. I know that in the editor I am using right now it's all getting stored / parsed out as Markdown. However for publishing I still find a What You See Is What You Get (WYSIWYG) editor to be my preferred method of blog writing. It's the closest analogue I get the final result in my browser and it largely matches my experiences in other non-tech editor spaces such as Microsoft Word.

I also don't really want to work in VSCode if I can work in my browser. I write code in VSCode and I want separate tools for separate responsibilities.

So I had a look at [Netlify CMS](https://www.netlifycms.org/) and am yet to try (but am eagerly looking forward to trying) [Forestry](https://forestry.io/). These do somewhat fill the gaps I am looking for, but I'd rather not be tied to an authentication provider to make these work if I am going to be moving to static site generation. I'm not sure this is an odd opinion to have, or one that even makes sense. The goal of moving to static site generation allows for flexibility of hosting options, from S3 to Azure, Google Cloud or even self hosting off a Raspberry Pi. Thus, it feels counter to me to lock myself into an auth provider for my server-less CMS. Perhaps this is my major hurdle to enlightenment, letting go and creating "yet another login™".

## Oh, I have to make that now...
The benefit of using a CMS is (in my opinion) being able to leverage the combined efforts of a larger team. If I want tags, they exist. If I want to schedule a post my server can do that too. If I want multiple authors I can make that work as well.

Now I can do all those things myself too. But like the rest of us I have limited time resources and I like to use those doing a myriad of things. I don't want to spend 10's of hours writing new features for my site or debugging ones when they go wrong. I don't want over complicated GitHub Actions or serverless Lamba style functions that send dummy commits to my repository to simulate scheduling posts. It's fine but it all seems like a workaround, with far limited user (and developer) experience just to replace something that doesn't seem that bad to me.

If I want to preview my website before it goes live I don't want to jump into a GitHub Pull Request to see it, I want to just open the preview in a new tab. It's not just about when I want my content to come out but how I can best manage it while it is in draft also.

The JAMStack promises flexibility and no reliance on any particular technology. A blank canvas is daunting and easily leads to over-engineering of things that really should be intuitive and simple. I'd argue that for most personal blogging platforms the 1-Click style installers that live on most shared hosting solutions are far less a barrier to entry, even to developers, than using the JAMStack.

---

![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/niy4fkdrdjuxhoa6xkoi.jpg)

## Static Sites & Headless CMS
I feel like there is some nice middle ground where I have a headless CMS, connected via webhooks to go and trigger a new static website build. It feels like a nice marriage between many of the perceived benefits of a JAMStack site with the added benefit of a better publishing user experience.

There is just one catch though, if I have a headless CMS that I am paying for I might as well use it to also serve my content. It's true that paying for a VPS is a relatively cheap exercise these days, particularly for low traffic blogs like mine. But they still do incur a cost so if I were to suddenly get famous (maybe off this very post) the cost for me to scale sufficiently would be problematic. I could, as an interim solution, split between serving my website statically but generating content on my headless CMS but now I am paying for two resources and not consolidating to one.

I know it's not all roses over here on the Headless CMS side. In some respects I feel locked into my current provider even though I self host. By writing content in a WYSIWYG Editor my posts are now not portable. If I do need to pick them up and move them tomorrow, or cross post them elsewhere I really don't have a good solution for that. I think in this respect the JAMStack shines and is one of my key motivators for moving.

---

## Where to from here?
Dear JAMStack community. Where should I be going from here? My goal would is and [11ty](https://www.11ty.dev/) based site running either Forestry or a competing serverless CMS. I could fairly easily port this website over the 11ty, in part because Ghost uses the same markup language. I could either port all my posts over and try Forestry, or I could continue to use Ghost with the 11ty starter.

For regular content authors what was your approach to moving to the JAMStack and was it worth the effort? I'd love your feedback.