Originally published at Codegram's blog

Note: This post's title could also be called forget about Wordpress and Drupal but after a bit of thinking I thought it wouldn't be a fair comparison since they're also really good tools. But in a way, it would be. Well, keep reading to find out why!

Hello! So if you're here, you've probably heard about the JAMStack already, or you're curious about it. Cool cool cool. I was too - hopefully, this post will probably save you some time if you're looking to get started into it.

What's the JAMStack?

The word JAMStack started being used just a few years ago. It stands for JavaScript, APIs, Markup as stated on their official website. It's not about specific languages or technologies, but rather an abstract definition of a runtime & deployment chain.

The term was coined by Netlify - but the tools & concepts behind it have been there for a long time. It just turns out that when presented together, they pack a lot of punch:

• Statically generated sites
• Using the latest JavaScript frameworks & libraries
• Leveraging APIs (REST, GraphQL, or anything else)
• Deploying to a CDN
• Atomic deployments
• Automated deployments via WebHooks
• Plays really nice with Serverless

The benefits it provides are generous:

• Unbeatable Time To First Byte : Since we'll be using CDNs to serve our whole request cycle, the time spent by the browser trying to get our first bytes of information is only limited by the CDN.
• Zero-time deployments: There's no boot time associated with deployments, which means new deploys or rollbacks are instantaneous.
• Security: The surface area for attack is greatly reduced, as most of our requests are now served by battle-tested CDNs that don't have direct contact with our APIs.
• Simpler model : JAMStack's is a nice breeze of air in a world dominated by Docker, Kubernetes, Buildpacks & such.
• Straightforward scalability: If your website isn't using APIs at run-time (the website is entirely statically built), you'll have the certainty your website can't go down because of a huge spike in traffic.
• Decoupling presentation from data : By separating the data source from the actual application, we get a greater choice of technologies. While this is true for many SPA, going the JAMStack way forces you, which is RealGood™️.

No doubt, no doubt. Should I use it?

As most technologies, the JAMStack is not for everyone. But it certainly is the right tool for you if you're building:

• A website that's mostly public, backed by a server-side CMS (say WordPress, Drupal, Joomla...).
• A Single Page Application
• Any kind of typical monolithic application that has a lot more reads than writes.

It might have other use cases, but at the moment these are the scenarios where I've felt myself most comfortable using it. And I'm really loving it.

A good use case would be Smashing Magazine: they're running on the JAMStack!

How does the developer experience look like?

I've previously said one of the huge selling points of the JAMStack is the developer experience. Here's how a regular development day will look you if you embrace the JAMStack:

1. You write your website in your favorite technology: Vue, React , or even plain HTML/JS/CSS - in practice, you'll use some of the build tools I'll talk about later on. You tie its rendering to some external API's data, namely a Headless CMS (I'll talk about it after a bit too!)
2. You push your website to your favorite Git provider: GitHub, BitBucket, etc.
3. During your deployment, your website fetches all the needed data from your APIs and gets statically built , generating a bunch of HTML, JS & CSS in the way.
4. Your site gets published to a CDN
5. Users visit your website and get served static data all the way along, so you don't have to worry about scaling your APIs - the data is embedded in your markup.
6. When your content changes on your source of data, a webhook gets fired, rebuilding and redeploying the whole website.

You can probably already see how all this plays extremely nice with automation tools like GitHub actions or even Zapier. Huge win!

Sold. How can I start using it today?

I'm sure there's a lot more tools and services I'm missing, but here's a compilation of the ones I've had experience using and I can actually recommend!

Web application frameworks

The first step in building our JAMStack-enabled site will be selecting our framework-of-choice.

Gatsby

Gatsby is one of the most ambitious projects to support the JAMStack. Built with React, it allows embedding nearly any kind of data source into their internal GraphQL database for you to query. All the queried data will get statically built into the templates, making it blazing fast!

In my experience, working with their GraphQL api can be a bit cumbersome and somehow limited, especially when it comes to relational data or other complex queries, but my experience is limited and a bit outdated - this might have changed on the last few months. That said, it's a great project with outstanding innovations like automatic responsive images, PWA support out of the box, and more.

Gridsome

Gridsome is a newcomer and the Vue equivalent (equivualent?) to Gatsby. Still in its early stages, it looks really promising.

While it lacks the bigger ecosystem Gatsby has, it has picked up on their latest features and improved on them, and I personally expect it to move quite fast. Their documentation is getting better every day.

We've build the website for Full Stack Fest 2019 with it, and it's been great. Just check out how fast it is!

Nuxt.js

Nuxt is the dominant framework when it comes to building web applications with Vue.js. Inspired by Next.js (its counterpart in the React world), it provides a statically generated mode that will embed the data used in your pages in your HTML templates.

There's only one gotcha: Calls to the original data API will still happen on page transitions. It looks like they're working on it and they're conscious of their limitations, based on our recent tweet exchange.

Nuxt has great support for i18n and a big ecosystem. Worth checking it out!

Headless CMSs

The big eye-opener for me has been finding out that I can definitely delegate the CMS to an external provider. While some use cases are calling out for a tailored backend, most use cases are simple enough that can configured via a UI. Nobody likes having to reinvent the wheel over and over!

There's many of them, but I'll only describe the ones I have actually tried in production.

Contentful

Contentful is undoubtedly the biggest player out there and has recently received a 33.5M$ funding round, so it isn't going anywhere.

Its backend is quite simple and flexible to most use cases, including support for I18n fields, content relationships, a rich HTML content editor, and more. However, it's unexpectedly expensive. They have a free plan that might work for most use cases, though.

Their data is exposed via a REST API, but they have a GraphQL one on bigger plans though.

Prismic

Prismic has an outstanding UI and user experience. It has support for I18n documents, associations, responsive images, and many kinds of fields. They also have tools for working for the major JS frameworks, a great querying API, and more. They're working on a GraphQL API as well which will be hopefully available to the public soon!

My experience working with them is pretty extensive and so far their response times have always been steady and reliable (which is one of the core things you're looking for when delegating your content to an external platform). Worth checking them out!

Deployment platforms

I'm sure there's plenty of options out there to deploying static content, but I'll list just what I can recommend:

Netlify

Netlify it's just perfect for the JAMStack — notably, their CEO came up with the term — so expect it to support everything they need and more, including:

• Cached, automatic builds
• Deployment previews, sync'd with GitHub's PRs
• A/B testing
• Support for Serverless functions

My experience using Netlify has been amazing from moment one. Did I mention they're free for individual plans?

No, I'm not working for them or nor do I have any kind of agreement. I just love it.

Your CI of choice + S3 + [CloudFront|CloudFlare|.*]

As in the end you're only deploying static sites, using your own CI to lint & build and then deploy to AWS S3 or similar is perfectly fine. You will just have to write part of the pipeline; rollbacks, deploy previews, etc.

My recommendation : If you want to leverage your own CDN, just back it with Netlify 👌

Giving you some time to rest and let it sink

Things that I've learned working with the JAMStack

Rebuilding after every change is totally fine

If your website isn't incredibly dynamic by nature, rebuilding after every change is perfectly fine: you're consuming CPU time in advance in exchange of saving the time spent on the runtime by your server mangling with html strings. Isn't that a great tradeoff? After all, aren't we throwing thousands of hours into our CIs already anyway? As an example, we have a webhook that rebuilds our Full Stack Fest 2019 website every time a podcast episode gets published. Working with client projects, we set it up so the whole site gets rebuilt every time a news article gets published (which happens several times a day).

Highly dynamic content can also be served

If some of your content is highly dynamic, there's nothing wrong with it — you can always resort to consuming an external API on runtime. This is the case for comments, for example. Gridsome, Nuxt & co allows you to defer the rendering of part of your component tree to the client. This is actually great for UX - the user gets server-side content as soon as possible, while the rest of the page gets load asynchronously. This also works for admin panels, private user areas & more!

It's nice having your HTML back

Having your application boil down to a bunch of static files kind of reminds you how the web was in the GoodOldDays™️. This enables new possibilities like Progressive Web Applications , publishing to the P2P web (see Beaker and DAT) & more!

It helps with SEO

While sometimes a limitation, not being able to dynamically change your served content depending on the client's headers (see I18n) forces you down a path that actually helps with SEO. That, and the fact that the content gets served blazingly fast, adds up to a happy google bot.

I want moar

Pheeew, that was quite a brain dump!

If you're eager to learning more about the JAMStack, here's some great resources to learn from:

• The Full Stack Fest 2019 conference (which we happen to organize at Codegram) features Brian Douglas , one of the original proponents of the JAMStack and he's also the host of the JAMStack radio podcast. Boom, shameless plug!
• JAMStack Newsletter: A newsletter about the JAMStack curated by Netlify.
• Awesome JAMStack: A compilation of resources following the awesome-* repo series.
• Other resources : The JAMStack website features other resources like talks and articles about it.

Thanks for reading this and I hope it will help you get started into the JAMStack world!

Looking for someone to help you build your next project on the **JAMStack? Throw us a line at hello@codegram.com and we'll be glad to help you!