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.
Originally posted on www.stackbit.com.
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.
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.
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.
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.
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.
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:
It takes a lot to bring an idea to life on the web, even for the simplest of sites. Follow this guide for a detailed look at moving from concept to a website deployed to your domain.
Learn how to take a handful of static HTML files and convert them into templated files that will help you minimize errors and work more efficiently.