JAMstack is one of those buzzwords that leaves the listener confused whenever it’s uttered (see also PWAs, blockchain, and serverless). Despite the name, JAMstack is a fantastic choice for front-end web applications, and definitely worth your time as a front-end developer.
Unfortunately, you have to have a solid understanding of web development technologies before explanations of JAMstack start to make sense. So let’s start with the basics.
The first is the old-school server-rendered route: build your pages in HTML/CSS/JS ahead of time and let the server serve those. Or you could have the server build those pages with a templating language (handlebars, EJS, jinja, etc) as requests came in. The downside here was that either your content was static (that’s no fun), or your server was doing a lot of work. Plus, each time the user requested a new page they would see a white screen as the server built/found the page and sent it to the user’s browser.
This always made me think of those signs you see in restaurants and mechanic shops. You know the one:
We offer three kinds of Services:
GOOD - FAST - CHEAP
…but you can only pick two.
It turns out there’s another option. This is where things start to get sticky, though. Single page applications are already difficult to think about, and typically we like to think about them as using client-side, on-demand rendering only. However it’s now possible to mix and match dynamic and static content on both the client and server.
There’s two main camps using this hybrid methodology to web app rendering and delivery. The first is server-rendered single page applications, and the second is JAMstack.
The only problem with this method is that, again, you need to maintain your own server. Running your own server is much more costly than a static hosting solution (using someone else’s server). There’s also some potential security liability involved.
You’re probably thinking this is a bit silly. The whole point of an SPA is to have a dynamic, on-the-fly rendering of your application at any given point, right? If you pre-render everything, what are you left with?
The answer is a lot, actually. When we build a single page app, we often have various routes or views baked in that don’t change. You may have a “home” page, an “about” page, and then your “main” content. Those home and about changes don’t really require dynamic data to render anything, but with a traditional SPA they’re rendered dynamically all the same. Even the “main” stuff probably lives on a route in some kind of wrapper component, right?
The result is an SPA that has a fast initial load, instead of a long initial load, meaning a great user experience without the cost and maintenance of a server.
Gatsby and Gridsome are more purpose-built for “static”-site generation, while Next and Nuxt are swiss army knife tools that allow you to do both server-rendering and static-site generation.
Note : There’s a lot of confusion about Static-Site Generators (SSG). A traditional SSG (Hugo, Jekyll, etc) takes your templated code and generates static HTML files from it. Gatsby and Gridsome are actually a lot more than SSGs. They allow you to smartly pre-build and template content in a lot of various ways.
For example, this blog is built from markdown files, and at build time, Gatsby compiles the markdown files into a React application. You could also query an API or CMS like Wordpress to get your data dynamically at build time. However you’re still free to make API calls at runtime too. You’re still building a React app. You’re just pre-rendering some of it.
JAMstack is really about making awesome websites without running your own server, or at least decoupling your “static” front-end from your back-end data sources. The front-end app should be composed of static files only and be its own codebase. That means no server-rendered content.
This sounds a little restrictive, but trust me, you can build a lot of dynamic content following these rules. Just about anything you can build with create-react-app or an SPA can be a JAMstack site. You can build Blogs, e-commerce sites, marketing pages, and full on web apps all with JAMstack methods.
Clear as mud, right?
I had a lot of questions on my journey to understanding JAMstack. Let’s try to address some of those points of confusion.
You have to rebuild the site/app everytime you update something that is pre-rendered. So if I make a new blog post, I have to rebuild the site and redeploy it.
Ah yes, consider the scenario where you make a blog for someone else. They probably don’t want to write posts in markdown and push code to github, right? That’s OK! You can automate your build step. If they make a new post, all you need to do is trigger a build to happen.
Netlify CMS is based around this idea. The user makes their edits on a dashboard (also an SPA), and when they “save”, they’re really committing the code with git, which then triggers a rebuild.
Ah, but you can do that too! You’d have to host your own Wordpress server somewhere, but Wordpress has a JSON API. When your user makes a new post, you simply have to trigger your static site to build somehow. If you’re using Gatsby or Gridsome, the build step queries your Wordpress API (or any other CMS, really) for all the available posts and builds the site.
That’s OK! You can still do all the things we just talked about, and just make a API calls for comments on the fly at runtime. You could build your own comment microservice, or use a premium service FaunaDB to store comments for you.
Typically, you can have faster page loads and a much better user experience using JAMstack methods. Also, because your front-end is detached from the server, security issues are greatly diminished. Plus, it’s mostly free or at least very cheap to host a static site.
If all of your front-end content needs to be generated on the fly, JAMstack is not a great choice. For example, if you need dynamic routes, that makes it very difficult to build a static front-end app. Similarly, if you’re building a server anyway, maybe it makes more sense to serve the front-end as well.
Sure! I’ve built a whole mess of them.
- My blog - Built with Gatsby, hosted on Github Pages
- The Tech JR Podcast site - Built with Gridsome, hosted on Netlify and mp3s stored on AWS S3
- Babelfish, a translation app - Built with Gatsby and Google’s translation API, hosted on Github pages
- Goaler, a todo app - Built with Create-React-App and Firebase, hosted on Github Pages
- This Pokedex App - Built with the Vue CLI and the Poke-API, hosted on Github Pages
JAMstack, like most great technological trends, is a pretty awesome solution with a crummy name. It’s not a perfect solution by any stretch, but it empowers front-end developers to build all kinds of sites and applications using their exisiting skills.
So what are you waiting for? Get out there and build something!