Skip to content
loading...

re: What is JAM Stack VIEW POST

FULL DISCUSSION
 

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

 

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 😂

code of conduct - report abuse