Introduction: Revisiting Decoupled Websites

The concept of decoupling content from presentation is nothing new: scores of developers accustomed to classic application development with databases and APIs have applied this principle for decades.

However, on the web it has been a struggle: many legacy CMS systems and e-commerce platforms have strongly tied data and presentation capabilities together. Many marketing websites have large parts or entire pages almost completely hard-coded - either to save on time, to reduce dev resources and infrastructure, or because they needed to prioritize short-term tasks over long-term flexibility.

In recent years, a generation of Headless CMS offerings has matured - with each having their own content model (e.g. here and here).

At the same time, Static Site Generators (SSGs) such as Jekyll, Hugo, Eleventy and Gatsby have made it easier than ever to fetch content from anywhere and transform it with templates into an easy-to-deploy website with good performance and no moving parts.

In our blog, we have covered how to use these for decoupled websites (for example, in our guide to Eleventy part one, part two).

Unfortunately, there is no common standard to modeling content. Most content-driven systems leave a lot to be desired: it's typical to see websites using modern CMS's to model a few disparate pieces of data and content needed for your website: blog posts, specific pages elements, perhaps the hero banner, maybe the link in the top navigation bar. However, it is much less trivial to define a content model suitable for visually building full pages, with all the affordances needed.

This is where Stackbit comes in: the bast layer underlying our whole product is the content modeling capabilities we offer. We've designed our model definition spec to be flexible, compatible with external data sources, and mostly: suitable for visual editing of complete websites.

All page layouts, components, nested objects and site-wide configuration in our themes are based on models. You can use these models as-is, extend or override them, or completely build your own.

Next up: Where does content live?