4 min read
The Jamstack is evolving. Where did it start, and what does it look like in 2021?
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.
A brief history of everything (web)
<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.
Generating static sites…dynamically?
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.
New tech to the rescue
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.