The JAMstack is a methodology for building web apps that is based on client-side JavaScript, reusable APIs, and prebuilt Markup. I think that the emphasis on build-time rendering has interesting implications for all web developers, and I made a little video about it while working on a presentation about it for a group of Back-End developers.
I tried doing it in a fun “pop-up video” style, and I’d love to know what you think about it!
What is JAMstack?
In short, “JAMstack” is a convenient name for a set of best practices that is centered on build-time rendering and Content Delivery Networks. The first 3 letters are an acronym: JAM => JavaScript, APIs and Markup.
The “stack” is harder to pin down. It doesn’t mean “stack” in the same way that things like LAMP or MEAN do – a combination of prescribed technologies that work together – instead it refers to a set of best-practices that work together to provide benefits that are greater than the sum of the parts.
The name “JAMstack” is a bit controversial, and I don’t know if we’ll still be using that term in the future, but I do think that the ideas behind it and the best practices are here to stay.
Below is a list of notes that correspond with the video.
JavaScript
- Client-Side JS (Important!)
- Framework agnostic, Vanilla JS is fine too!
- No server side rendering, the only server we’re dealing with here is the build server
APIs
- All server-side processes or persistance are abstracted into APIs
- All APIs are accessed over HTTPS from the JS
- Treat your own server-side components as 3rd parties too!
Markup
- Templated markup should be prebuilt at deploy time
- Modern site generators are great at this
- Main idea is to treat your content as data, separate from your design
Best Practices (aka the “stack” in JAMstack)
- The app should be distributed on a CDN, the more on the edges, the better the UX
- Modern Build Tools: Bable, WebPack, Gatsby, etc
- Everything you need to run the app lives in a single git repository – simple npm install
- Remember FTPing? Watchers more common now
- Focus on automated builds, there is less emphasis on persistance, so changes generally need to be deployed
- Atomic deploys (deploy everything at once instead of file by file)
- Instant cache invalidation (use a CDN that can handle instant cache purges)
- Read more about the best practices
The Benefits
- Better performance via static files/CDN
- Cheaper scaling (CDN)
- Security (Server decoupled from the front-end)
- Better Developer experience
- loose coupling
- targeted coding and debugging
What is NOT JAMstack
- When your VIEW is not fully client-side (means tightly coupled front-end and back-end)
- Building views at run time (ASP Razor, Ruby, Node can be used for APIs, but not the view)
- Things like WordPress that require an application server like PHP for rendering html to users
When not to use the JAMstack
You can’t get the benefits of build-time rendering unless you’re actually able to render some data at build-time. If you’re site has lots of real-time data or the data is specific to the user then there isn’t much benefit for you – your JAMstack site is basically just a SPA at that point.