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 😂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 😂