At Ample, our journey with the Jamstack model began well before the Jamstack as we know it existed. In 2010, our small-but-mighty developer team (which was really just Taylor) was motivated to no longer deal with aging, monolithic applications, and began to use the Jamstack methodology. When the Jamstack philosophy got coined in 2015 by Netlify, we were excited — we were doing that anyway!
Today, we swear by the Jamstack methodology, and were even named a finalist for 2021 Jamstack agency of the year. The Jamstack can be a confusing concept for many developers. To help shed some light on the subject we went right to the source, interviewing five experienced Jamstack developers from our team to break down their understanding of the Jamstack.
The “JAM” in Jamstack originally stood for JavaScript, APIs, and Markup. Today, the Jamstack is a term that more broadly refers to…well, we’ll let the developers explain.
The Jamstack is a philosophy that solves many operational challenges created over the last 15 years of web development, including performance, scale, cost, complexity, and developer experience challenges.
Additionally, all the derivative benefits that come out of that value proposition have really moved the needle on maintainability of our software and being able to craft really good and creative experiences.
The Jamstack is not anything new. It isn’t some really exciting, new tech or new modern approach. In fact, it’s a reversion back to the way the web was intended to work — which is static assets, with zero security vulnerabilities.
So I said “Holy shit, this is exactly what we’re already doing, but now I don’t have to glue it all together and answer all the questions.” Plus, there’s a marketing apparatus attached to it that I can leverage to educate clients and get people on board.
When you strip out all the complicated stuff, you’re left with the bare-bones, pre-rendered version of your website that is then getting delivered back to the end user. By doing that, you can start leveraging tooling and workflows that comport with what developers want today.
Developers are always hard to please and they will come with a bunch of opinions. I always make this joke that if you put five developers in a room, they’ll come back with 10 opinions about something. In a lot of ways, that is a hard nut to crack as you try to attract new talent, remain competitive, keep your costs down, and make sure you can maintain sites for the long term. There is a ton of benefit in this ecosystem that comes from reducing complexity.
Crossroads: We migrated Crossroads off of their legacy “monolithic infrastructure.” Monolithic infrastructure basically means everything was tightly coupled so that if the database went down or the web server went down, it would bring their whole system down.
When we migrated off of that, we leveraged Netlify’s gradual migration solution to piecemeal portions of the site from the old system onto the new system. The benefit of that is we drastically reduced the risk for the organization. Unfortunately, it’s not cheap to gradually migrate. However, by handling it in that fashion, we were able to satiate concerns among the team and the stakeholders and we could control the process and solve problems in real time.
84.51: This project was different in that it was a “big-bang” cutover which is not uncommon. Instead of taking a gradual page-by-page approach, we built the whole thing and stood it all up at once. This method is a little more stress-inducing, as all eyes are on that website at go-time and if you run into problems, reverting after the fact can be costly. But it worked out and now they’ve got all the same benefits of any Jamstack site… decoupled architecture, scale, performance, increased security, etc.
These are both examples of successful outcomes, although how we got there was slightly different for each.
It’s funny in this day and age, whenever you’re approaching a new technology or new philosophy, it’s like “Crap, here’s something else I have to learn.” The beauty of the Jamstack is that you actually have to unlearn certain things.
I think a lot of folks, particularly more junior-level developers, overthink it. They’re asking “Well wait, where does the magic happen?” But there is no magic. You’re just putting text files on a content delivery network (CDN) and then giving that to your end user. It’s faster and there’s nothing to exploit.”
That’s really powerful because instead of taking long round trips through a database layer that can ultimately serve to degrade performance, now we can globally distribute it all and get it in front of users in milliseconds.
When I started reading about what the Jamstack is, I thought, “I’ve already been building websites like this.” I realized Jamstack is essentially about defining a solid process around this specific front-end stack.
I like the Jamstack because I’m a front-end engineer, so I don’t need a back-end person to reach out to. I can essentially do it all myself.
I have been liking GraphQL, which is a tech that is supported by the Jamstack. It has some weird quirks, but it’s essentially a replacement for those back-end calls, so I’ve been really enjoying that aspect of it. I’ve been able to hit these headless CMSes as opposed to maintaining a Wordpress server.
I would just say you’re thinking about it too hard. That’s probably what I was doing when I was first thinking about it. It’s really just a methodology a lot of people have already been using, and you’ve probably built websites like this before.
One of the core aspects of Jamstack is static HTML build, and you could say that 90s websites were a straight-up HTML build. That’s an extreme example, but just don’t think about it too hard. It’s just front-end stuff.
The Jamstack is really just any set of tools that allows for static files to be put on a CDN, and also allows for separate services to be stitched together to make a website.
I would say the speed and the user benefits to having the static files on the CDN. It could be global, so no matter where you’re at in the world, it’s roughly the same speed.
I would say the UX and speed improvement. It makes it easier for us to make websites faster with less effort. Across the board, that’s something that’s difficult, so it makes that easier.
The advice I would give is the same for just about any other technology, and that’s to focus on the fundamentals — HTML, CSS, and JavaScript, and don’t worry so much about what tool you’re using because they’re all going to use those tools to build it. That helps if you understand the underlying technology.
The Jamstack is a set of technologies that allow you to solve seemingly difficult problems in a clean and maintainable manner.
I like the flexibility that it has. The original idea of static site generators was that your website would be more rigid, and with modern development patterns and technology, but that’s not the case anymore. If you develop a Jamstack website with a good pattern and a little bit of forethought, you can accomplish a quick and responsive website with good SEO, as well as dynamic content that’s catered to unique individual preference.
I use the Jamstack for a blog — that was my first introduction to the Jamstack, actually. I had weighed the pros and cons of using a pre-existing website-building tool, but I didn’t like them, so I used Hugo, which is a static site generator. It was a perfect solution to what I was looking for, so I was able to make that website super quickly and it was really easy to make changes to it, too.
The advice that was useful to me was to try to understand it one piece at a time. You don’t have to know how to use the whole Jamstack immediately — you can work on the independent pieces and get good at those before you commit to being a Jamstack expert.
Additionally, maybe one of the most important things that applies to all web development is that frameworks aren’t the only option. You don’t have to pick React or Angular or Vue. Those are very JavaScript-focused type things, and the Jamstack kind of acts as a bridge between those more intense, purely front-end-focused items and content management and more ease-of-use for a content manager.
The Jamstack is built on the principle, old-school internet where pages were done when they would serve you rather than having to do all sorts of complex stuff. So we’re rebuilding pages, and then serving them to people. That makes serving pages much more performant and secure. And it’s scalable, because it doesn’t matter if you do it for 10 pages or 1,000 or 10,000.
The Jamstack has got an amazing ecosystem right now. There’s a lot of innovation in the space. It’s not as static and one-trick pony as you would originally believe it to be. You can still do pretty much anything you can do with the traditional setup of a website with the Jamstack.
One thing I really love is because the pages are cached, you can have preview URLs, so it’s super easy to collaborate. When you have preview URLs, everybody else can look at the work you’ve done, what it will look like, and how it will operate. That includes every stakeholder — from other developers to people on the design team, and even the client. By decoupling the front end from the back end, you can focus on delivering work which is nice. There’s less internal friction and the whole thing improves collaboration for stakeholders.
Yes. That’s mostly because of the speed of execution. I was asked to spin up a prototype for a search functionality, and normally that would have included a lot of setup. But because of the Jamstack, it’s so easy to actually spin up a webpage that I had the skeleton for that up in essentially a day. I was able to deliver something to the client in a fraction of the time it normally would have taken.
The simple concept of it is: If you have 1,000 visitors to the same complex page a day, and they all see the same page, then there’s no need to build that page 1,000 times. When you have it cached, they just get the page. It’s done. You already have it. So that is just computing time we don’t need. That’s the super-simple explanation of why it’s beneficial.
I’d also say don’t underestimate the capabilities of the Jamstack. It’s super easy to think that because it’s static pages, you can only do the most simple web page, which is absolutely not true. Especially with the new developments in the space, more and more it gives you a very easy setup but you can configure stuff the way you want it and you can still make complex web pages with the Jamstack.
I’ve heard a lot of people say, “Well we have this-and-this functionality, we won’t be able to do that with the Jamstack.” But almost in all cases, because of the use of APIs, you actually will be able to do it.
I would also suggest looking into what websites actually use the Jamstack, and you’ll be surprised. That’s what I did. I didn’t use the Jamstack before Ample, and at first I was like “Well...you can only build the simplest stuff.” But once I started looking into it, it turns out Google has stuff they do with the Jamstack, and I thought it was really cool. Jamstack.org also lists a bunch of websites that use it.
We hope that at least one of our developers’ explanations helps you understand the Jamstack a little better. Interested in learning more? Check out the Jamstack page on our website with more content around our favorite methodology.
Want to join our team of talented Jamstack software engineers? Check out our careers page or send us a note today.
Sign up for our email newsletter. Nothing spammy about it. Just a monthly rundown of what we’re sharing.
