JAMstack sites are characterized by their fairly “static” nature. They consist of mostly static assets that are pre-generated ahead of time and served to the end user with minimal latency via a CDN. Because JAMstack sites favor pre rendering content at build time, they can seem antithetical to dynamic sites where content is “dynamically” fetched at request time from the server. This assumption is deeply predicated on the dichotomy of static and dynamic (This is unsurprising given that in the english language static and dynamic are in fact antonyms.) In the context of the web, static and dynamic are separate ends of a spectrum. A site can be at either extremes of static and dynamic or be anywhere in between. By giving developers the option to prebuild while also tapping into a rich API ecosystem and leaning on JavaScript for interactivity, the JAMstack sits comfortably at the intersection of static and dynamic.
Serverless functions add an extra layer of dynamism to JAMstack sites. They provide a way to inject dynamic content to sites and respond to user feedback in realtime. In the case of a forum where comments are an integral part of user interaction, comments can be implemented via a serverless function that reads and writes to an external database. This is in contrast to the traditional approach of building out a monolithic application to handle one or two pieces of dynamic functionality. Serverless functions therefore enable developers to add dynamism to their sites while also isolating tasks into functional elements that are more efficient (no need to over provision servers) and maintainable in the long run.
If serverless functions still confuse you, check out Tara's deep dive into what serverless is. And if you're not sure how to use serverless functions, here's a piece to get your creative juices flowing.
Top comments (2)
When it comes to this vocabulary, I also like to distinguish between the site's architecture and the user experience.
My experience has been that some larger "dynamic" back-ends, which had lots of infrastructure and complexity, took far more effort and time to update and iterate. The result being that the experience they provided was sometimes very static indeed.
Conversely, by being able to host a site statically, complexity can be reduced and iterations and update cycles can be far more rapid and regular. Leading to a site with fresher content, and a more dynamic experience.
Automation, and triggers, and modern workflows all allow a "static architecture" provide a more dynamic experience. And that's even before we add some of the things like serverless functions and calls to APIs from client-side js.
Loving this #jamuary series!
I really like this distinction! It helps clarify what we really mean when we say "dynamic"