Does the JAMstack still use servers?

A common contention around the JAMstack paradigm is that the lack of servers is a misnomer. Though the JAMstack ethos claims to serve content without web servers, servers still play a crucial role in the JAMstack when it comes to executing and serving content statically. Taken at face value, the assertion to move away from servers is a touch misleading. However, the main premise of the JAMstack is a departure from traditional approaches to web development where content is rendered dynamically on a server. On the JAMstack, content is instead pre-rendered and hosted statically from a CDN. The server (in the traditional sense) only ever runs at build time and sends static assets to the CDN which caches them for delivery upon request.

It’s worth noting that there is a distinction between a CDN and a traditional web server. A CDN or content delivery network, helps speed up the access and delivery of website assets via a distributed network of edge servers. Compared to a web server, an edge server is an entry point into a network and serves as a connection between disparate networks. As a result of its existence at the “logical extreme” of a network, (static) content lives as close as possible to a user and can be served up with minimal latency and/or page load time. This is in contrast to origin servers where 100% of content is rendered on the fly for every single request. When relying on an origin server for content, latency becomes an issue since every request must be routed through to the physical location of the origin server regardless of where that request comes from. Because internet traffic is limited to the speed of light, the further a user is from an origin server, the longer the request time. By serving content statically from a CDN, the JAMstack therefore speeds up request times drastically, thereby giving users a lightning fast experience.