Divya is right here but I think it's largely a problem of the term "serverless" being a bit of a misnomer, which kind of confused me when I first started looking into this methodology.
Yes, it's not SERVERLESS but really what you're not doing is investing in a dedicated server to run your web apps; instead of having to manage your server you're leveraging SERVICES like GitHub, Netlify and AWS to host, build and operate your site.
For me, having had to run websites with a LAMP stack for pretty much all of my career, not having to worry about DevOps and being able to leverage the kind of continuous deployment that you get with GitHub and Netlify is a breath of fresh air - as yet there are specific, really heavy use instances where I can see I'd want to go back to building a site with, say, Wordpress, but there have been many instances in the past where Wordpress and the associated infrastructure required has felt heavy and expensive for simple websites; the Jamstack ideology makes building and deploying such sites an absolute doddle.
The JAMstack ethos of moving away from servers, is similar to how serverless doesn't mean no servers. What this approach pushes for is a movement away from dynamically rendering content on a server and instead hosting content statically from a CDN. In that regard, it's a movement away from the traditional way of serving content server-side. So yes, you're right in that last sentence.
Also to your comment on HTML pages still living on servers, there is a distinction between a CDN and a web server. A CDN is about speeding up the access/delivery of your website’s assets to users by having a distributed network of edge servers. This is done by having your content live on the server as cached static assets. This is in contrast to traditional servers where 100% of content is rendered on the fly for every single request. Not only does this require a full round trip to the origin server to serve content, it also takes far longer depending on the user's latency and bandwidth.
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.
"The JAMstack is effectively a movement away from servers."
Nonsense. You call an API you use a server. You have an HTML page, there is a server.
No dynamic server-side rendering seems to be the real idea.
Divya is right here but I think it's largely a problem of the term "serverless" being a bit of a misnomer, which kind of confused me when I first started looking into this methodology.
Yes, it's not SERVERLESS but really what you're not doing is investing in a dedicated server to run your web apps; instead of having to manage your server you're leveraging SERVICES like GitHub, Netlify and AWS to host, build and operate your site.
For me, having had to run websites with a LAMP stack for pretty much all of my career, not having to worry about DevOps and being able to leverage the kind of continuous deployment that you get with GitHub and Netlify is a breath of fresh air - as yet there are specific, really heavy use instances where I can see I'd want to go back to building a site with, say, Wordpress, but there have been many instances in the past where Wordpress and the associated infrastructure required has felt heavy and expensive for simple websites; the Jamstack ideology makes building and deploying such sites an absolute doddle.
The JAMstack ethos of moving away from servers, is similar to how serverless doesn't mean no servers. What this approach pushes for is a movement away from dynamically rendering content on a server and instead hosting content statically from a CDN. In that regard, it's a movement away from the traditional way of serving content server-side. So yes, you're right in that last sentence.
Also to your comment on HTML pages still living on servers, there is a distinction between a CDN and a web server. A CDN is about speeding up the access/delivery of your website’s assets to users by having a distributed network of edge servers. This is done by having your content live on the server as cached static assets. This is in contrast to traditional servers where 100% of content is rendered on the fly for every single request. Not only does this require a full round trip to the origin server to serve content, it also takes far longer depending on the user's latency and bandwidth.