The way developers prefer to build websites has changed dramatically in the last five years. Thanks, in large part, to the Jamstack.
Jamstack opened the doors for developers to build sites that were more secure, scalable, performant, and cost-effective in an era when those achievements were earned with a headache at best. And at worst ... well, let's just say I used to have more hair.
What Made Jamstack Possible
The Jamstack movement was led by Netlify, the folks who gave us the final piece in the puzzle that brought Jamstack to life. (They also coined the term.)
But it wasn't just Netlify that made Jamstack possible. It was born of a convergence of several ecosystem advancements, including the commoditization of CDNs, popularization of static site generators, the API economy, and many more. I went into more detail on the emergence of Jamstack in this article.
Why Jamstack Caught On
All these things that made Jamstack possible were for developers. Git, static site generators, APIs. Website visitors and maintainers don't care about these things. Developers do.
The Jamstack is a developer-led movement.
And it's popularity grew not because of its benefits (faster sites, cheaper scaling, better security), but because it made achieving those benefits easier for developers. From this came an opportunity for developers to sell a solution that came jam-packed with a better developer experience because it also resulted in what website owners tend to care most about — cost, security, and performance.
Jamstack's Missing Piece
And the advancements were profound! While this movement wasn't without challenges, we were suddenly able to put more power in the hands of developers — to build more (and better) with less effort (and time).
But for all that power. For this entire game-changing revolution, we left someone behind.
Content creators.
All of a sudden, creators were thrown into this world of headless CMS, where the focus is structured data and not (necessarily) how content is rendered on screen. They were forced to meticulously understand the effect of every field on the front end of the site. There was no (easy and non-technical) way to preview content before it was deployed.
We had something designed to make developers' lives easier, and in turn ended up making content editors even more reliant on developers.
A Healthy Contract between Developers and Editors
At Stackbit, we're working to fill in this missing piece in the Jamstack. We believe we can build a healthy contract between developers and content creators by delivering a real-time, in-context editing experience atop code built with popular and tested open-source tooling.
It's a difficult problem to solve — to optimize a product for both developers and creators. But we think we're doing it!
And we're working toward a new chapter in our history as we begin unveiling a number of changes over the coming months. We're rethinking how our site templates are architected (we call them themes) by introducing a shared open source component library that will be used in every theme. And we're rolling out an entirely new editing experience — one that puts power in the hands of editors and the right amount of control in the hands of developers.
To get a sneak peek of these new features before they are released to the public, join our early access program. Hope to see you there!
To find some inspiration for this piece, I had a chat with our CEO, Ohad Eder-Pressman. Here's the recording of that conversation:
Before I joined the team, I found Stackbit to have an uncanny ability to find missing pieces of the Jamstack and work to fill them in. And we're on the cusp of taking the solution to that missing piece to the next level.
