The Wonders of Jamstack

This will be one of my more technical posts but if you’re still reading maybe you’re curious to hear my thoughts on Jamstack… or don’t have a clue what it is and may want to know a bit more…

What is Jamstack?

Jamstack is an approach to development and delivery of content, that uses JavaScript, APIs and Markup (JAM) to produce static, highly performant, secure, content delivery network (CDN) hosted projects.

A lot of the web has evolved over the years to use complex, database served content and code. Such websites and applications are reliant on being able to ‘build’ the page you’re looking at each time you visit. So when you visit a webpage, it will go off, grab the content from a database, and then plop that content into a predefined template, before finally showing you the page/view you were after.

Wordpress is a good example of this kind of approach to delivering content - it also adds the all important content management system (CMS) that allows people to create, save and publish the content they want to appear to their audience.

One of the issues with such a set-up is the reliance on a database, which can slow down the experience of grabbing and serving you the content you want to view. Yes, you can cache and streamline how this content is served… but ultimately, if you’re creating content using this approach, it will have to be saved in a database, then published out to be viewable.

As well as performance limits, there are also security issues with database reliant web content - they are vulnerable to security flaws, being hacked, and all manner of other nasties.

Why Jamstack?

Jamstack can be seen as an approach that takes things back to how the web started… but with some modern tech sprinkled on top for good measure.

Back in the days before Wordpress and other server-side options, you could (and still can) produce websites using just the simple building blocks of the web - HyperText Markup Language (HTML) and Cascading Style Sheets (CSS). They’re all you really need to be able to create a webpage - and all you need to be able to view and interact with content.

You could actually use only HTML if you wished, but it would be a bit of a basic experience - CSS adds the critical benefits of colour, layout and text styles that deliver a more palatable, browsable webpage. Javascript allows you to capture interactions and to manipulate the webpage in various ways, as well as allowing dynamic information to be served into the page, as it loads, if you wish.

Jamstack aims to deliver projects to users using just these basic elements (plus image/assets and the supply of external information/services via APIs). No reliance on databases and far less security concerns. You simply have fast, static files that contain your content, styles and visual assets.

The difference with the modern web is the evolution of JavaScript to create dynamic/interactive layers to the experience, either by compiling data into static files when they’re built for deployment, or through access to increasing powerful API services that can be called upon as the page loads. The whole experience can even be delivered via JavaScript alone if you’re looking at a framework powered app, for example.

Markup

Before we look at the JavaScript element of Jamstack, lets start with our all important content. How do you create, edit or manage the content for this wonderful new approach to delivering web-based projects?

Well with Jamstack, the content you’re dealing with should be abstracted out to simple, static files, or an API reference/call.

A popular language used to create such static content is Markdown. You can create Markdown by just typing into a plain text/.md file, or go for a more elegant WYSIWYG (what you see is what you get) editor - but ultimately you’re looking to seperate your content (markup) from the rest of your project as far as possible. I’m actually typing this very blog post in Markdown!

Not a fan of Markdown? You can actually use Wordpress (or a whole host of different solutions) to create the content instead. Yes, Wordpress will still save the content into a database, but you no longer have to rely on that database to deliver your content to your user… you simply store it there, safely tucked away from nasty malicious attacks, as it doesn’t have to be hosted in a publicly accessible place any more.

The key difference in using this approach compared to a standard Wordpress set-up is that when you’re ready to publish your content you use the Wordpress content API (yep, the all important A in JAM) to pull content into your templates and then compile them into static pages - so database calls are no longer required when the user wants to look at those pages. Still with me…?!

I get excited about this separation of content from the guts of your project, and the large variety of options you can use to produce/manage your content. Projects are no longer bound to database set-ups, a given platform, or even the format into which they can be published - it’s really very freeing.

My preference is for static content files (such as Markdown) because you can save these into source control. Jamstack projects are so easy to manage in source control platforms, such as GitHub. In fact, they’re pretty much designed to run from such services. Jekyll, the simple, blog-aware, static site generator was written by GitHub’s co-founder, Tom Preston-Werner, back in 2008 - and to this day it’s the engine behind the websites served from GitHub - GitHub Pages.

You work on your content, commit your changes to source control, then your content is compiled and squashed down into static files and published out to highly performant content delivery network (CDN) hosting.

JavaScript and APIs

I have to confess - my experience of Jamstack pretty much stops at websites. Or certainly just the serving of static HTML, CSS, Javascript, and the reliance on APIs to grab more dynamic content such as Instagram feeds, or handle form sending. Oh, and Cloudinary to compress, and crop my images. Turns out I use quite a few API services! My ‘apps’, based in Jamstack, focus on using pure JavaScript (by design) and no (funky) frameworks - not even our aging old friend jQuery.

JavaScript is instrumental in compiling my various files into the optimised, static files though. I use Gulp - a fantastic toolkit that streamlines so many aspects of my workflow: using babel and uglify to compile down and minify my Javascript, SASS compiling, autoprefixing and minification for CSS and HTML rendering/minification. Other such tools are available though - Webpack and Grunt, for example.

The Content Management Conundrum

Truth be told, I’ve never been a fan of Wordpress. Any database reliant projects have always caused me concerns over security and performance. It’s the reason I don’t use many plug-ins (and I’m very selective on the ones I do use), and I always build custom themes for any Wordpress projects I’ve developed. Couple this with the daunting client user experience of the Wordpress content editor… even with the release of the polarizing Gutenberg UI. Instead, I always look at the wider options for the client before choosing a CMS.

I may have said this on a previous post, and will most likely say it in a future one too, but I will always carefully consider which CMS or hosting solution suits a client, and their project, than just going for the same option each time.

Does this make things more problematic for me? Sometimes. But it means the client gets the best user experience, and a CMS/hosting solution that matches their requirements.

I’ve used PHP-based solutions such as Perch, Kirby and Wordpress in the past, when database solutions were more of the rage. As well as Jekyll sites, edited via CloudCannon more recently. I’ve rolled my own CMS solutions (um… not really recommended unless really necessary!). Finally, I’ve used a static site with a clients own social media accounts as the CMS. Using a combination of their Instagram, Twitter, YouTube and Tumblr posts - to seamlessly publish updates (via each platform’s APIs) onto their site… which was pre-Jamstack I hasten to add!

Netlify

How can I talk about Jamstack and not mention the darling of the movement - Netlify. It’s an amazing platform that is tailor-made for building and deploying static projects, from all manner of sources, with a rich toolkit of services.

Just connect it to your source control service of choice and watch as Netlify does preview builds of your pull requests, allows serverless Lambda Functions, split testing, form processing, analytics and even their own CMS: Netlify CMS. They’ll even host your generated content under a custom domain.

No, I’m not on commission! Netlify is simply one of the best services I’ve used for a long time, and does what the best tools do best - make my workflow better by being simple, powerful, efficient and frictionless.

They even organise the inspiring Jamstack Conf. It’s well worth checking out the talks from previous conferences if you want to take a dip into the pool of what Jamstack has to offer.

Generally, Jamstack gives me a huge suite of options to consider for projects, but with the knowledge I can get really performant code at the end of it. This ultimately leads to a better end-user experience, and a great client experience too.