There can be a lot of confusion around why Jamstack is becoming so popular or so widely used. How does it differ from other technology stacks? This animated explainer breaks down the answer to “Why Jamstack?” visually.
See the Pen why jamstack? by Sarah Drasner (@sdras) on CodePen.
The problem: With a traditional client-side rendering solution, the server delivers a file without content until you fetch everything and the browser compiles it. And if you’re far away from that server, the latency for the request gets larger.
With older server-side rendering solutions, the server compiles and fetches everything, builds the web page, and delivers a fully populated HTML page. It’s much faster.
However each time you navigate to a new route, the server has to do it all again- compile and fetch it all, and deliver it. This process delays the load, sometimes by whole seconds.
Recently, an approach called Jamstack has become popular, which addresses both issues. The whole site is built before deploying the content to CDNs, which means it’s geo-replicated across the globe. We never go back to a server on additional requests.
We call it Jamstack and not static, because it extends beyond static. We can make the page dynamic, with API calls or serverless functions, and the user can interact with it.
What’s more, because there’s no server involved, there are fewer attack vectors. Jamstack approaches improve performance and security! 🎉
Hopefully this small explainer gives perspective on this paradigm! More Jamstack materials are available to explore on Jamstack.org and our own Phil Hawksworth has a free course on FreeCodeCamp.
