Hmm, good point. (Sanity co-founder/developer here) Based on launch day feedback, it seems we did assume some of these concepts were more widely understood in the developer community than they actually are. We will recalibrate our messaging accordingly as soon as possible.
We don't actually like neither the "headless" nor "CMS" part of the vernacular, but it seems to be the least unknown description of our product category around.
The classical CMS provides a way to author your content married to a templating engine that describes how your content gets rendered to HTML. This last part is what is considered the "head" when we speak of a headless CMS. Simplistically a headless CMS is a CMS that provide an api to the content instead of rendering it as html. Then you write the "head" (i.e. front end) in whatever technology you prefer using those apis.
A fair question then would be: what's the big deal? Can't you just stick an api on Wordpress and off you go? That leads to the other, less obvious difference: A good headless CMS is focused on authoring the content as structured data so that it is clear to the presentation layer what each piece of information means. Take this project page from the OMA.eu site:
If you expand the Location, Year and Program parts of the metadata you'll see maps, timelines and charts. These are all rendered by the front-end based on long-lats, lists of milestones and area usage authored by the OMA editors. In their old CMS these would be uploaded as images and html-fragments, but with Sanity it is described as a structure of data-points with a defined meaning. This allows us to use those same data points to provide advanced search functionality (give me buildings widh 20-30% office space and more than 5% retail), and it has also allowed us to generate print-ready books from the exact same dataset that power their web-site.
The big hairy goal of a headless CMS is to disentangle the content from its presentation, and thus make the content reusable across many forms of presentations ultimately making the work spent authoring that content more valuable.
We don't actually like neither the "headless" nor "CMS" part of the vernacular, but it seems to be the least unknown description of our product category around.
The classical CMS provides a way to author your content married to a templating engine that describes how your content gets rendered to HTML. This last part is what is considered the "head" when we speak of a headless CMS. Simplistically a headless CMS is a CMS that provide an api to the content instead of rendering it as html. Then you write the "head" (i.e. front end) in whatever technology you prefer using those apis.
A fair question then would be: what's the big deal? Can't you just stick an api on Wordpress and off you go? That leads to the other, less obvious difference: A good headless CMS is focused on authoring the content as structured data so that it is clear to the presentation layer what each piece of information means. Take this project page from the OMA.eu site:
http://oma.eu/projects/timmerhuis
If you expand the Location, Year and Program parts of the metadata you'll see maps, timelines and charts. These are all rendered by the front-end based on long-lats, lists of milestones and area usage authored by the OMA editors. In their old CMS these would be uploaded as images and html-fragments, but with Sanity it is described as a structure of data-points with a defined meaning. This allows us to use those same data points to provide advanced search functionality (give me buildings widh 20-30% office space and more than 5% retail), and it has also allowed us to generate print-ready books from the exact same dataset that power their web-site.
The big hairy goal of a headless CMS is to disentangle the content from its presentation, and thus make the content reusable across many forms of presentations ultimately making the work spent authoring that content more valuable.