DEV Community

What is JAM Stack

Leo Melo on May 13, 2018

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...
Collapse
 
thatfrankdev profile image
Francis Cote • Edited

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.

Collapse
 
leomeloxp profile image
Leo Melo

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.

Collapse
 
cathodion profile image
Dustin King • Edited

Not sure to what degree this is intended as a joke.

Collapse
 
leomeloxp profile image
Leo Melo

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.

Collapse
 
kissu profile image
Konstantin BIFERT

Yep, he is just talking about the stack. Don't see at which moment you get offended tho.

Collapse
 
cathodion profile image
Dustin King

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.

Thread Thread
 
kissu profile image
Konstantin BIFERT

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.

Thread Thread
 
grantwparks profile image
Grant Parks

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.

Collapse
 
the_fln profile image
Francois Lanthier Nadeau • Edited

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!

Collapse
 
leomeloxp profile image
Leo Melo

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 πŸ˜‰

Collapse
 
the_fln profile image
Francois Lanthier Nadeau

Right on! Don't hesitate to poke our devs on Intercom, anytime. :)

Collapse
 
rrampage profile image
Raunak Ramakrishnan

Hi Leonardo,

Thanks for the post. I have a few queries:

  1. What is difference between a static site generator like Hugo / Jekyll etc and JAM? Don't most of the advantages of JAM stack apply to static pages (e.g page load time, no DB hit, fast rendering)? AFAICT, the advantages of both are in having an easy to deploy (and update), versioned content repository.
  2. Does it require the use of a cache like Netlify / Cloudflare? Also, you mentioned that it contains a single index.html and javascript file. So will that be an issue (due to changes in any content changing that file)

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

Collapse
 
leomeloxp profile image
Leo Melo

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.html file, 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 πŸ˜‚

Collapse
 
lauragift21 profile image
Gift Egwuenu

Awesome! Another Jamstack Fan. Nicely written i think the possibilities with Jamstack is endless btw I love the gifs on this post😎.

Collapse
 
leomeloxp profile image
Leo Melo

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.

Collapse
 
ranktutorials profile image
Ranktutorials

Congrats! Your tutorial was shared on ranktutorials :)