This post was based on a talk I gave at a local web development meetup in Jersey π―πͺ on May 4th, 2018. Enjoy!
JAM Stack
JAM stands for Javascript, API and Markup, an acronym with a nested acronym. π€
jamstack.org defines JAM as modern web development architecture based on client-side JavaScript, reusable APIs, and pre-built Markup.
Defining what JAM means doesn't really gives us enough depth though, is there any secret behind it?
Let's take a look at the file structure for an example JAM website:
As you can see, there's no magic behind it. Just a set of files that we're all used to seeing in the front-end aspects of our projects
Based on that file structure some could even try to argue that Space Jam's website is a JAM site (spoiler: it isn't, it doesn't even use CSS π).
What makes JAM so useful for us is on its Javascript and API aspects
Javascript + API =
If we look at one example of a JAM website built using Gatsby JS, Rachio Smart Sprinkler, we can see that for the end user, there are no immediate visual changes, this website is statically built and still offer full ecommerce and checkout journeys, with the help of APIs.
Why should I give myself the trouble?
Even if the end user won't really have any immediate advantages, there are a number of reasons that will encourage you to consider the JAM approach on your next project. Let's visit some of them:
Load speeds
No database querying: As your website's markup is built on build time, there is no database queries being done at every page request. This saves both on server load as well as overall response times.
No template parsing: Depending on your stack, chances are you have a template file in your code base that gets parsed and is used to build the HTML that gets sent back to the browser on every page request. With a static site that wouldn't happen, meaning you can also save on server loads and response time by taking this aspect out of the request/response flow.
Separation of concerns
Front-end takes care of all presentation
With front-end frameworks increasing in popularity and capabilities, having your website/application's presentation decoupled from any backend framework means you can harness all the power that your front-end stack gives you, and in turn deliver a better experience to your end users.
Centralised/focused UX design
Equally relevant, if you don't need to worry about how the backend of your application handles its data and business logic, you can focus more of your efforts ensuring that your user experience is at the level you want and your end users expect, without have any potential constraints imposed by backend solutions.
Frequency of content update
How often do we really update ALL our pages?
This is a point that is very often overlooked. For a number of our pages, content is rarely ever updated, eg contact pages, terms and conditions, blog posts.
You may update such pages a few times soon after they're published to fix potential typos or inconsistencies but once that period is gone chances are you will never edit that page again so why not have it statically built and save your server the hassle of having to compile this page on every request?
Frequently changing content can use APIs
If you have pages that still need to provide dynamic or time sensitive content, you can use APIs to update that content once the page has loaded and maybe cache that content on the client-side or (less optimal) include that content after the page has loaded.
No need to implement everywhere
There is no need to move your entire application to JAM all at once.
JAM Stack your blog
As mentioned above, certain pages are less likely to change after they've been published so making them static would provide you with increased performance and better experience for end users.
User authenticated areas could remain non-JAM'd
If your application has some sort of authenticated area where things need to be kept dynamic, you can skip that section when JAM'ing your application.
Progressive migration to JAM
The takeaway from this section is that you can slowly migrate your content to a static build, and bring in more API backed dynamic content as you identify the opportunities in your application for a JAM approach.
Tie in with service workers, SPA's and animated page transitions
JAM stack makes it easier for us to include new web workflows onto our applications, such as Service Workers, single page application frameworks and animated transitions between pages.
Offline support
With service workers you can make some or all of your website's content available to users when they're offline. This is a great feature, but specially important if your core market involves tourists or users with less than optimal internet connections.
Push update to service workers on build time
As I said earlier some pages would rarely change their content after being published, but when they do, you can use service workers to revalidate your content based on your needs. This will ensure your end users always have the most relevant content on their devices.
Page transitions make UX sleek (like on native apps)
This may not seem like a key feature of static and JAM based sites, but if you take a moment to think about how nice some native apps transitions between their different areas, it is really exciting to think that we can do the same on a web based application. See Sarah Drasner's page transitions example if you need some inspiration.
Caching
Lastly, caching a statically built site is even more efficient than a dynamic one as you can cache all aspects of your site and depending on your content type your cache can be set to extremely long expiry dates.
For any portions of your site that need to be dynamic, you can use the Javascript and APIs aspect of JAM to pull in content after the page has loaded.
Caveats
As with most things in our area, there can also be trade-offs or at least things that you should keep in mind when crafting your JAM based application. I already touched on these above but for the purpose of having all of these under one section, a few caveats to consider when building JAM apps are:
E-commerce and extremely time sensitive content
If your content is extremely time sensitive and relies heavily on a backend solution, JAM may not be the best option. One way to circumvent this would be to use APIs to update the content on the front-end, but this may not be possible all the time.
Must implement SSR
There are many reasons behind this, but it's always recommended that you implement some sort of server side rendering logic at least at build time, for your content.
Ensure no JS support if relevant and SEO best practices
I know this may sound a bit dated, but implementing no JS support can be very relevant depending on your target audience or the percentage of users you want to deliver your application to. It's worth mentioning that no JS support could be slightly limited when compared to the full application, but it's important to give no JS users at least some sort of consistent experience.
Depending on the type of website or application you will also want to ensure that you're covering your grounds in terms of SEO. Having a great website could mean nothing if no one can find out about it.
Authenticated areas of your app
Authenticated areas of your site may not always be compatible with the JAM approach. Again, APIs can help you here, but it's up to you to make that call for each individual case.
A few suggestions on this would be to SSR the chrome of your site, and maybe add some placeholder markup to indicate that the user specific content is still being fetched with AJAX/APIs.
How can I join the JAM Stack hype train?
Now that you have seen some pros and cons of JAM, you may want to try it out for yourself. There are plenty of ways you can build a JAM based website and most of these have some sort of static site feeling to them.
I compiled a list with some options you could try, but this is by no means a comprehensive list, just things that I came across or used myself in the past.
React is probably the most widely used front-end framework these days and if you know React you probably know all these options. Either way, these are a few tools that you can use to build a JAM stack:
- create-react-app: Great zero config React application scaffolder with the possibility to eject your app once more custom features are needed.
- GatsbyJS: A static site generator for React with a built in GraphQL data layer and the ability to built static HTML from your React components on build time.
- Next.js: A framework for server-rendered React applications with support for static sites.
Vue is also a front-end framework that has been increasing in popularity and adoption very quickly. If you're using Vue, these are a few of the tools you can use to build JAM apps:
- Nuxt: Universal Vue JS application framework, often said to be the Vue equivalent of Next.js,
- VuePress: Static site generator for Vue.
- eagle.js: A hackable slideshow framework built with Vue.js (used to create my talk's slides π€).
Other options
- Jekyll: Ruby based static site generator, widely used for GitHub Pages.
- Hugo: Go lang based static site generator.
- StaticGen: StaticGen offers a list of static site generators that you can sort and filter based on your preference or needs.
- Build your own: NIH syndrome aside, if you have a very specific set of features that you require, you can always build your own static markup and integrate it with your APIs in a way that suits your business and needs.
JAM friendly backend solutions?
One other important aspect of JAM stack is ensuring that your backend solutions integrate well with front-end frameworks and provide APIs that you can harness from the front-end/client-side of your application. A few examples of frameworks and services that can help you with that are:
- Headless WordPress: Using WordPress as your CMS doesn't necessarily mean you need to use it to generate your website's markup directly. API-first/Headless WordPress is something that is increasing in popularity and plugins and libraries to help you get started are out there.
- Netlify CMS: A file based CMS that can plugin in directly into your version control and build workflow.
- Prerender : SEO friendly plugin to your application that ensures your website can be crawled correctly by search engines
- Your current framework of choice: This may not be as obvious for all CMS/frameworks but chances are you can already build a JAM website and integrate with your current backend solution, possibly by using REST and/or GraphQL.
Conclusion
Thanks for reading my post. JAM stack is awesome and I believe it's the most efficient way forward for us. When you get to your next project, consider giving JAM stack a try, or maybe consider rebuilding portions of your current set up using JAM, you won't be disappointed. π
There are probably tons of things that I didn't talk about (and consequentially are not part of this post), feel free to mention things I may have missed in the comments.
Some inspiration for my talk was taken from another dev.to post on JAM Stack and I recommend you check it out:
The slides for my talk can be seen here, you can also check out the Github repo with the slides' code. Cheers π€
Top comments (16)
Nice post, thanks for sharing this. One of the great benefits of the JAM approach is you can pick and choose the services you need and compose them into a complete solution. Auth0 for authentication, Filestack for file upload, ImageBoss for image processing, etc.
Plus, you can benefit from all the serverless solutions out there to help you craft custom interactions and behavior.
Quick note on e-commerce : Although I agree that selling products doesn't seem to fit naturally in a JAM context, tools like Snipcart can help you transform a static product catalog into a fully transactional store. Check it out! Also, the Snipcart blog is filled with neat JAMstack gems.
Hey, glad you liked the post. All these services that have been popping up around JAM approaches are really great and help so much with adding extra functionality to our applications without the need for complex microservices set up on a first party level.
Complementing your note on e-commerce, there are an increasing number of solutions around checkout journeys and carts for JAM/static sites, another example I recently came across is Foxy, formerly known as Foxy cart.
I used e-commerce on my talk/post as a potential challenge for JAM more because I often hear people trying to use it as an argument against using JAM but that does not seem to be the case as much anymore.
Not sure to what degree this is intended as a joke.
Haha, this is not a response I was expecting I must say. I saw your reply below about "a new VR game" but it seems I can't reply to that so I'm writing it in here.
Unfortunately, I wasn't the one coining the term JAM stack, and I can see why you wouldn't call it a stack per se. In a more traditional or strict way, I think JAM would be more of a paradigm or workflow even.
I believe, and someone more informed could correct me on this, the reason we call it a stack is because normally when we (or at least I) ask people how is their application built in terms of libraries and techniques, I ask "What is your stack?"
In this case, I don't normally want to know if it is hosted on a Windows, Ubuntu or CentOS server or if they are using Apache or nginx, but rather, if it they're using React, Vue, Angular, GraphQL/Apollo, Redux and based on their answer I'd then continue to ask how they manage to bring all of the chosen tools together.
Hope that adds a little bit more of context to why JAM and how it's not really a joke, but a set of practices and/or methods that we should think about when building our applications for the web.
Yep, he is just talking about the stack. Don't see at which moment you get offended tho.
Not offended at all, just not sure whether to interpret as a joke: here's a new "stack" but it's really just using things people are already using. Like if I said "here's a new VR game" but it's really just going outside.
Or if it really is a new way of looking at something that exists, like taking "best practices" from some set of what people are already doing, while giving guidelines to avoid some of the pitfalls.
Not sure if 1/2 years ago, people were into this stack. Now it's kinda popular and people get a lot of stuff around that makes it viable: headlessCMS, easy to deploy platforms, more enthusiasm towards PWAs, simplified universal/SSR (not only SPAs) etc...
A lot of tech is released daily in the JS world. But all of it do not always last.
But here, the JAM stack is kinda welcome by a lot of people and will probably last. I mean, it's like GraphQL, it wasn't released a week ago but it's still considered as 'new' because it get past that initial hype train.
I think what he's saying, and I second it, is that there is nothing, not a thing, new here. Unless you're excited about generating static pages ahead of time. As far as "there's no db to query". Excuse me, if you're using an API, there's dbs being queried. And how much utility is there in using only 3rd party APIs? If you're doing something real, then you're writing the API, so you do all the server stuff. This architecture is known as client-server, it's been around a long time.
Love to see devs spread the word about the JAMstack. Thanks for that, Leonardo!
Few resources that could come in handy, addressing some of your points:
JAMstack e-commerce examples
β’ A Tutorial to Bundle Cockpit CMS & Nuxt.js in a full JAMstack
β’ Static Site E-Commerce: Integrating Snipcart with Jekyll
JAMstack backend & serverless examples
β’ Staticman for User-Generated Content on a Jekyll Static Website
β’ Handling Static Forms, Auth & Serverless Functions with Gatsby on Netlify
β’ Webtask's Backend-as-a-Service: A Serverless E-Commerce Tutorial
JAMstack client education
β’ JAMstack for Clients: Benefits, Static Site CMS, & Limitations
I'm obviously biased towards resources on Snipcart's blog, since I work there. But we do spend loads of time crafting JAMstack resources and tuts, and I'm confident these will bring value to the table. :)
Cheers from QuΓ©bec!
This is awesome, thanks for the great resources!
As someone that currently works at an agency (that hasn't fully embraced JAM yet), having more information to share with my team and our clients is extremely helpful, thanks.
Will also keep Snipcart in mind for potential e-commerce projects π
Right on! Don't hesitate to poke our devs on Intercom, anytime. :)
Hi Leonardo,
Thanks for the post. I have a few queries:
From your post and the linked dev.to post, I think that it will be good for single page web-apps like calendar, email and provide offline support. But I am not sure of the use case for blogs and simple web pages as it adds more complexity like SSR for JS. Am I missing something?
Thanks,
Raunak
Hey Raunak, thanks for raising these questions. Hope this helps answer, let me know if you need any more info π
Question 1
The way I see it, JAM can work as an extension to static sites as well as in an environment where some server side rendering/routing is in place, eg when using Next.js.
You are right about all the points that static sites and JAM have in common, but the Javascript and API parts of JAM highlight that the static site can use AJAX for example to bring in content when the static content alone is not enough, or to add extra functionality on top of a statically rendered application.
Question 2
Using a caching or CDN is not a requirement for JAM, but because JAM relies purely on HTML, CSS and Javascript files, setting up caching or content delivery becomes a lot easier, so you have fewer reasons not to do so.
As for the single
index.htmlfile, my example would be the simplest form of JAM. In a more realistic scenario we would have a few html files for individual pages and a number of CSS and JS files to complement them, most likely generated by a build process or bundler such as Webpack/Parcel.Regarding use cases for blogs and simpler web pages, you might want to only use the static site aspect of JAM. The point in here would be to avoid having a DB on the back of your blog for every single page request, or having your backend parse template files to generate the content every time. the JS and API part of JAM then would come in place for things like contact form or comments section (likely by bringing in a server less solution or 3rd party in most cases, such as Disqus or Facebook)
Sorry if my reply turned out a bit too long π
Awesome! Another Jamstack Fan. Nicely written i think the possibilities with Jamstack is endless btw I love the gifs on this postπ.
Cheers π I totally agree that JAM possibilities are very much endless. I guess it's a pro from the fact that it's not set to a fixed number of actual libraries but more of how the libraries come together when building our apps.
I can't wait to see more new and creative ways JAM websites will come about.
Congrats! Your tutorial was shared on ranktutorials :)