18
Jamstack 2.0
It's time we officially bump the major version of Jamstack to 2.0. The term "Jamstack" has always been a bit of a marketing success for a general architecture idea, but most developers took it to mean 90's era websites with nothing but static files on a CDN. The latest frontend framework and serverless infrastructure features are combining to shake up the game - Jamstack is growing up.
Early websites really were nothing more than static documents and browsers were glorified document viewers. Javascript wasn't a thing and styling support was basic (and vendor specific). Developers wrote CSS and HTML by hand, more often than not banging their head against a wall trying to use nested <table>s to layout the entire page.
The next big evolution on the web brought us server-side rendering with monolithic backend frameworks built on Ruby and PHP. The ability to serve up content customized to the person viewing it was huge, and the option to programmatically render pages allowed sites to grow much larger than anyone would have done manually writing every page in markup.
Then things really got interesting. The backend became a bottleneck and logic started moving back to the browser with client-side javascript. This trend really took off with libraries like Angular, React, and Vue. There was one problem though, returning a mostly empty HTML page with a handful of <script> tags is terrible for search rankings. Until recently, Google's search bots didn't even run client-side javascript and would have no idea what was in a purely client-side rendered site.
Jamstack is really a pretty generic term at the end of the day - any site that uses Javascript, APIs, and Markup fits the definition. Until recently that was usually assumed to mean static sites only - pages built with SSG tools like Jekyll or 11ty hosted entirely on a CDN. That was more a sign of the tooling limitations at the time though, not a limitation of what Jamstack was functionally meant to be.
How can my site be static when it needs to show user-specific content like order history or messages?
This question inevitably comes up when talking about Jamstack, and rightfully so. What is the use in pre-rendering a page if all the content changes for logged in users? There is an SEO benefit to serving real content to anonymous users, but you definitely don't want your valuable registered users to see the entire page flash and re-render when the pre-built page is replaced with content specific to them.
We're starting to see javascript frameworks like Gatsby and SvelteKit give us the option to partially pre-render sites. Maybe you want to pre-render 90% of a page's content but the last 10% needs to be filled in with user-specific content. Maybe you want to pre-render the most popular pages of your site but leave the rarely requested URLs to render when requested.
Combine these framework features with infrastructure like Cloudflare Workers and Netlify Functions and things really get interesting.
Have hundreds or thousands of content blog posts on a site? No problem, build the handful of main pages once and delay building all your blog posts until a visitor requests the page. Even better, you take advantage of your CDN to cache the built blog post so the serverless function doesn't have to fire back up for the next visitor wanting to read that post.
I'm really excited to see how well frontend framework features like incremental builds tie together with building and caching at the edge with serverless functions. It's a tight needle to thread and there's definitely a risk debugging could be a nightmare, but if done well the value to both developers and site visitors could be huge.
Projects like Astro seem to be pushing it even further, taking advantage of native ESM imports to lazy load javascript components on the fly. Astro hasn't even been released yet, so we'll have to wait and see how it works, but the concept of combining the best of static site generators like 11ty with frontend libraries like React and Svelte might just be crazy enough to work!