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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
Not sure to what degree this is intended as a joke.
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.
Yep, he is just talking about the stack. Don't see at which moment you get offended tho.
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.
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.
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.
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!
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 😉
Right on! Don't hesitate to poke our devs on Intercom, anytime. :)
Hi Leonardo,
Thanks for the post. I have a few queries:
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
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.htmlfile, 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 😂
Awesome! Another Jamstack Fan. Nicely written i think the possibilities with Jamstack is endless btw I love the gifs on this post😎.
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.
Congrats! Your tutorial was shared on ranktutorials :)