How This Blog Works: JAMstack

April 14, 2020 · 3 min read
backend frontend blogging gridsome

JAMstack sites are fast Photo by Luca Campioni on Unsplash

The dev blog. A place where you can shave that goddam yak as much as you want.

When I looked for my tech stack I had three goals in mind:

  • A blazing fast website
  • A modern web stack, so I can tinker as much as I want
  • A good editing experience

With this vision, JAMstack was the perfect fit!

JAMstack = client-side JavaScript, reusable APIs, and pre-built Markup

On the internet, you will find many (slightly different) views on the definition of JAMstack sites. For me, JAMstack means:

  • Pre-rendered HTML
    Most front-end frameworks offer server-side rendering by now. This means we can pre-render all static parts of an application, resulting in faster load times for the website visitor. But your site doesn't need to be only HTML and CSS. Your apps can first load their HTML and then hydrate into a fully functional React, Angular or Vue application.
  • Static hosting on a CDN
    CDNs store your web app data on a globally distributed cache, so your website visitors have maximum download speed and minimum latency. Most CDNs also do cache invalidation for you, so visitors always get the newest version.
  • Using APIs for dynamic content
    Dynamic in this context when content changes happen frequently and non-predictably, like with comments. APIs can mean to use external solutions like commento for website comments.

JAMstack is easy to get started:

  • Pick a Static Site Generator (SSG)
  • Use Git
  • Choose a CDN
  • Set up CI to build your site and push the update to your CDN on every commit

Blogging Stack

After some forum-digging and experimenting with various technologies I settled on the following tech stack:

  • Gridsome
    I wanted to start fast with one of the Gridsome starter templates And I definitely wanted to work with TailwindCSS and offer a dark mode. This lead me to the Gridsome portfolio starter by Andrew Madarang. I adjusted it for my purposes and continue to work on it.
  • GitLab
    GitLab is my go-to Git hosting option I love GitHub and only have a slight preference for GitLab, because it is open-source and offers great built-in CI pipelines.
  • Netlify
    I looked at several static hosting options, including surge.sh, Zeit Now, and GitHub Pages. Surge.sh and GitHub Pages seemed too simple and don't have the highest speed. So I went with Netlify, because contrary to Zeit Now it has built-in server-side analytics. Server-side analytics is a great and privacy-friendly way to get (limited) insights into the performance of my posts. I like to pay for services so they stay in business. The free features from Netlify are enough for me, and Netlify analytics is in a perfect price range at $9/month.

Editing Workflow

Most of my work happens in Roam. I capture ideas there, summarize articles I read, and draft my own posts.

My process to write an article for this site is:

  • Take an article idea from my ideas page and make it a separate Roam page
  • Note the questions I want to answer and the reader take-away
  • Write a first draft of the article, with all relevant links to other posts or to my sources
  • When the draft covers everything I want, take some time to shorten it and rearrange text where necessary
  • When I am happy with my draft, I copy it over into a markdown file in my blogs Git repo, polish the text and add an image.
  • My last step before committing is to run that text through ProWritingAid to fix errors and make the text more readable.

Final Words

My goal with this blog is to be useful to people on the internet. I'm not doing this for short-term success (which isn’t very probable). I'm in this for the long run. I genuinely want to help people. And I want a place to tinker on and learn in public.

Only commit to things you're willing to do 100 times.

Create Every Day. Teach Everything You Know.

Back to Blog