A Jamstack Primer for Beginners
One major advantage of the Jamstack is its easy integration with CDNs to quickly deploy highly-performant static or pseudo-static pages, making it a solid choice for sites with a lot of relatively unchanging content like magazines and blogs. Similarly, the use of headless CMS as a backend makes it easy for said journalists and bloggers to upload their work using an intuitive web interface (no web dev skills required). It’s my personal opinion (an opinion which, coming from a very green developer, should be taken with a considerable amount of salt) that the name Jamstack name undersells the role of CMS and CDNs, but I suppose JACMSCDNMstack is a mouthful (I like to read it “Jack McDenim Stack”).
If you’re getting started with web development, you may have heard of a few of the tools in the Jamstack toolbox: React frameworks like Gatsby and Next.js, frontend build tools like Webpack and Grunt, or Headless CMS like Contentful and Strapi (or Biilmann’s own Netlify) without getting a whole lot of context for how they work, or, more importantly, how they work together. So, let’s start by taking a closer look at the acronym:
As I pointed out before, one of the advantages of the Jamstack is the ability to quickly serve up static pages. However, that characterization may leave a bad taste in developers’ mouths. Static is HTML. Static is the web in the 90s. In his 2016 talk, Biilmann pointed out that static is seen as a dirty word and gives the wrong impression of just what a Jamstack site is capable of. Sites do achieve big performance boosts by using static site generators to pre-render as much content as possible during the build process. However, Jamstack sites also use the concept of hydration whereby the client expects markup on client and server sides to be identical, which allows a framework like React.js or Vue.js to takeover on the client side after a static version of the page is rendered. This gives sites the performance benefit of static pages served from a CDN while maintaining the ability to dynamically display and alter content for things as simple as searching or as dynamic as displaying the time and weather.
There are a slew of open-source frameworks and static site generators built to manage the pre-rendering and hydrating processes of Jamstack development, each with its own philosophy and capabilities. A few of the most popular ones include:
- Gatsby: Billed as “a React framework,” Gatsby works with React and GraphQL
- Next.js: Another React framework with a fairly different philosophy to Gatsby that focuses on server-side rendering
- Hugo: HTML/CSS Static Site Generator written in Go
- Jekyll: HTML/CSS Static Site Generator written in Ruby
To their credit, the documentation is great for all of the above and you can easily get started with minimal know-how in the respective language (I built my first Gatsby site in a day).
A is for APIs
Frontend developers, rejoice. With Jamstack, you’ll never have to build your own server or database again. But you can. But you don’t have to! APIs play a huge part in making the Jamstack tick. Of course, you can build your own API, but if you’re doing something like blogging or photo hosting, why reinvent the wheel? You can take advantage of headless or “decoupled” CMS to hold all the details and Jamstack build tools will regenerate your static pages when things change.
What is Headless CMS?
For a long time, content management systems were coupled with a frontend. They didn’t just hold your content, they also had a lot of opinions about and control over how to display your content. Think of the old days of WordPress blogs. Headless CMS decouples the frontend and backend to serve up your content via an API. This front-end-agnostic approach gives us a lot of freedom in accessing and displaying our back-end data without building the API ourselves. Some good CMS include:
But Wait, There’s More
The API tie-in doesn’t end at content management. A vast API economy has grown up around the need to offload the complexity of services like payment processing and live chat. Jamstack sites take advantage of this API economy to pull in these advanced features without worrying about security and added complexity. Some services might include:
M is for Markup
I won’t lie, when I started writing this, I wasn’t thinking about the M. Markup is pretty straight forward, and we fairly well covered it in talking about static site generators. Just as a recap, what makes the Jamstack so performant is the ability to serve up mostly static pages that are generated by markup. This could be HTML, but it could also be Markdown. Lots of static site generators come with the ability to create pages directly from .md files — one more reason Jamstack is great for blogging.
If you’re in backend development, don’t worry, Jamstack isn’t coming for your job. Jamstack probably won’t displace LAMP, MERN, MEAN, etc. The proliferation of SPAs and PWAs will go on unabated. Plus, all the SaaS and PaaS companies making content management and cloud storage solutions need plenty of skilled backend engineers. However, Jamstack sites do fill a certain niche, and the tools are getting more powerful each day. Plenty of companies, entrepreneurs, and bloggers might find Jamstack more than sufficient to achieve their goals online.
If you want to learn more you can go straight to the source: Jamstack.org