Does JAMstack mean having to pre-render all the things?

As the JAMstack ecosystem matures, the debate over what counts as “truly JAMstack”™ continues. Given the elusive nature of the term and its recent-most evolution, its unsurprising that there remains some confusion over this. The JAMstack stands for JavaScript, APIs and Markup, and emphasizes the intermingling of these pieces to build websites that are scalable, performant and overall efficient. A key component of what makes a site JAMstack is its pre-rendering capabilities or how much of the site is generated ahead of time. The focus here of course is not on the implementation per say, but on the results instead; So a successful JAMstack site is determined by how fast and delightful the site is to work with rather than whether it uses a specific technology. To attain the end goal of fast, secure sites, the JAMstack approach encourages pre-rendering assets at build time. Frontloading the build step means serving your UI statically, which has significant benefits when it comes to performance and server costs down the line.

The JAMstack however doesn’t preclude serving assets dynamically. A SPA for instance still counts as JAMstack as long as it pre-renders parts of the UI (like data fetches or an initial app shell) to dynamically load content into. The idea of the JAMstack in a sense follows a similar ethos to the progressive enhancement movement. Start from the premise of pre-rendering content statically and then progressively add runtime elements like API calls and JavaScript. This way sites can effectively serve content well while providing delightful and meaningful experiences to users.