Brian Rinaldi, a developer relations professional at LaunchDarkly, was a little intimidated to talk about the meaning of Jamstack at the Infobip Shift Conference in Miami last month. That’s understandable because earlier in the day’s schedule, Matt Biilmann, the CEO of Netlify who coined the term, had already defined “Jamstack.”
As with any discipline, the frontend has its own jargon which sometimes makes it hard to tell what’s a real technological change or function and what’s just, well, marketing lingo, Rinaldi noted. In his talk, he drilled down on the origins and meanings of common frontend terms.
He started with static site generators, which were the big thing when he became a frontend developer around 2010. Static site generator (SSG) wasn’t the most marketable or understandable term for developers and companies didn’t really buy into the idea of them, he added.
“Static site generators take a bunch of assets and pre-render them and generate out static files that you can then deploy,” Rinaldi explained. “The problem with that is that when you describe something as static, it sounds old…. My site isn’t static, my site has interactive things, my site has all this going on. There’s no way I could possibly use a ‘static site generator’.”
Also, before the Jamstack, the LAMP stack was popular, Rinaldi said. LAMP stands for:
“You can think my site uses JavaScript, APIs and markup, even though I’m writing in PHP, [so] is that Jamstack? No. So it’s not a very prescriptive stack in that sense. It was more of a conceptual spec,” he explained. “We were doing static site generators, with some sprinkling of JavaScript on the client side that basically enables you to add in some dynamic stuff, maybe even call some external APIs. But other than that, it was largely static.”
In some sense, the Jamstack described more of a long-term vision for what might be, he added. Gatsby was brand new in 2015 — the year Jamstack became popular — and web developers were primarily using tools like Hugo and Jekyll, and sprinkling them with JavaScript, he said.
Then Biilmann came up with the Jamstack. It became popular, as did Netlify, Vercel and other companies that supported a Jamstack approach, he said.
“The idea was basically, you were talking about sites that were still more or less static sites but basically it laid out this idea of the JAM being JavaScript, APIs and markup,” he said.
Things started to change around 2022 when serverless functions became a frontend trend. The meaning of Jamstack also began to expand, as jargon terms are wont to do, he said.
“We’re now using serverless functions and we’re doing more than just static sites [for] a lot of this, maybe we’ve added in server-side rendering, and all kinds of other stuff. Things got a lot more complicated,” Rinaldi said.
In order to accommodate the complexity, Jamstack got a bit of a redefinition, he said.
“You may have noticed that JAM is no longer capitalized because it’s not all about JavaScript, APIs and markup,” he said. “There was actually so much confusion at the time about it. … Losing the acronym made sense, but we also broadened the definition. So this evolving of terminology that we talked about, where jargon tends to expand to meet all the things that get added on. And so at this point, it became … much more vague.”
Then came the full-stack JavaScript frameworks, such as Next.js and Nuxt, and companies like Vercel and Netlify started to support serverless functions and backend functionalities.
“I looked at Jamstack as an umbrella term, and then we had all these other terms that kind of fell underneath it,” he said. “At this point, Jamstack is kind of broad and diffuse, but we have a lot of other more specific jargon that describe all the techniques and everything that fell under this umbrella.”
One of the ideas Biilmann talked about at Shift was decoupling. Decoupling is hard to explain, but easier to understand when you consider the alternative to decoupling, Rinaldi said.
“We were trying to create an alternative to this monolithic architecture,” of WordPress, which he called the “canonical example of a monolithic architecture” because it required everything to change on the frontend whenever there was a backend change, because frontend and backend were so tightly coupled. Developers wanted to decouple the backend from the frontend.
“We’re not just trying to support a web application, we’re trying to support mobile applications or voice applications or other types of application,” Rinaldi said. “I don’t want to have to maintain one set of content here for my web application, that then I’m repeating that same thing for my mobile application in a different system because they can’t speak to each other. Decoupled architecture allowed us to be a little bit more flexible in how we build things, but also support multiple different front ends with the same back end.”
That leads to another commonly bandied-about term: Headless.
“At the time, monolithic CMSs [were] the big thing […] like Drupal, which did the frontend and the backend,” he said. “There was no way to kind of decouple those two pieces. So companies like Contentful, and others, kind of came up with this idea of maybe we just need the backend of the content management system and […] you can connect whatever frontend you want to.”
Then web development gets concepts like headless commerce, which is essentially the backend of an e-commerce system without a tie to the front end, he explained. That allows the developer to put whatever front end they want onto that back end — and that’s why it’s called headless, he explained.
“Pre-rendering is just honestly a fancy word for saying something’s static,” Rinaldi said. “I’m going to explain why there is a legitimate reason why using this more complicated version — […] pre-rendering, as opposed to static — is a better thing, and that’s because when you get into types of renderings, things get a little complicated.”
Related terms include CSR for client-side rendering, content rendering, and single-page applications or SPAs, he said.
“Your single page application was basically rendering everything in JavaScript on the client, in the browser,” he said. “We would then use hydrate — another jargon — we would hydrate the application with new content by basically calling data from the content data, the backend API, and then hydrating that on the client. But all that rendering portion was done on the client.”
Whereas with server-side rendering, instead of hydrating the client all the time, every request sent over re-renders the page on the servers and sends it over, he added.
“I joke that server-side rendering is what I’ve been doing, and I started building websites 25-plus years ago. We were doing server-side rendering, but if you talk to developers now, you’d think it was [first] attempted two years ago by React,” he said. “We’re moving a lot from client-side rendering towards server-side rendering because the performance of content rendering, particularly on devices — the bundle sizes, and all this other stuff — can cause a lot of problems. So now you’ll notice frameworks, even React, starting to move towards server-side rendering with things like React Server Components, and so on.”
Many newer frameworks are solely focused on server-side rendering, he added. SSG, or static site generation, goes back to that pre-rendering idea, he contended.
“The reason I like to think of it as pre-rendering is because static site generation makes it sound like it’s different from server-side rendering,” he said. “It’s not as distinct as you might think. Basically, static site generation is server-side rendering at build time, and then pushing it out. … Ultimately, it functions the same.”
Other similar terms he cited as trying to describe basically the same concept — what he termed “deferred rendering” — but each is done with a slightly different implementation:
“The idea here is if static site generators and server-side rendering had a baby, it would be this,” he said of ISR, DPR and DSD. “Basically, it’s the first call to a page, I will render it on the server, cache that [and] in some cases, even add it as a static asset to the actual output of the site. But it’s only done on demand. So that’s why I call it deferred rendering because it’s like we were basically static rendering the page, but doing it on the first request, and then serving everybody else who comes after that this static version.”
This allows developers to cut down on the build time, while also getting the benefits of static state generation — which will be fast, he added.
Composable is a term used by Netlify frequently, and some developers see it as a marketing term that basically means “an enterprise version of Jamstack,” said Rinaldi. That’s not true, he said.
“It’s really much more focused on the backend,” he said. “In fact, … it’s not even concerned with what kind of application you’re building on the frontend. You could have a composable architecture that talks to a mobile application, you could have it talk to a web application.”
Whereas Jamstack was very focused on how developers build a website, composability takes a broader view — though it is more of a practice for large organizations, he added.
“I have all these different APIs, now I need to create this whole kind of backend for frontend pattern where I might have a layer on the frontend that’s just trying to weave together all my backend APIs,” he said. “Now we need to get the customer data from the customer API to get the customer ID to then pass it to the orders API to get the orders. You’re weaving together this complex stuff, often coming from different systems and different APIs. And it was hard to pull all that together.”
Composability ties those pieces together, making it easy to drop the pieces in. Composability platforms tend to use GraphQL because it’s the most common way to tie together multiple APIs into a reusable API, he added.
“You can do […] composable and Jamstack together. They’re not mutually exclusive: Your composable backend could connect to a Jamstack web application, they work together,” Rinaldi said. People often complain about it being “too enterprise-y,” he added but that’s because it solves an enterprise-level problem.
Finally, he explained the term MACH, an acronym for microservices, API-first, cloud native SaaS and headless. MACH architecture is both composable and modular, according to the MACH Alliance. It’s often used with the term composability. MACH is a “slightly more prescriptive version” of composability, he said.
