When I saw the OMA and DS+R logos on your marketing site, I thought no way it's the Architecture firms...prob some niche technology companies in Europe.
But lo and behold, you guys did build their new websites! For the HN crowd, OMA and DS+R are at the top of the field...as a tech analog maybe comparable to Stripe and OpenAI.
I've been diving deep into the finding the right headless CMS and so far have found most either lacking or too expensive (Contentful anyone?). At the moment, hacking away at Netlify's React CMS, but it's a struggle.
Excited to check out your product especially since it's used for architecture firms I love and respect!
This feels like a CRUD app builder disguised as a visual programming tool. I generally avoid those things because they are hard to debug or extend.
Perhaps this is different because of GraphQL?
In this case, I would typically reach for a battle-tested CRUD building framework like Rails that gives you JSON APIs for free. I am not as familiar with GraphQL frameworks, but I suppose that I could find one as well if I really wanted that.
I am not really sure what people mean by "CMS" anymore. I have always thought of it as a place for people to create and publish pages. It is confusing to me when people use it to mean a structured database.
Sanity.io designer / co-founder here. We've been discussing how to explain what Sanity is and stuck with “CMS” to give people an everyday use case, casting a new product category in something old. There's the term «Headless CMS», but that doesn't capture the data modelling and query capability well either.
And for sure, this way of thinking about content isn't new. People have been building bespoke relational databases with custom forms on top since forever. But it has been time consuming and also pretty hard to get totally right. It's free form in data structure, but expensive to change.
Many who haven't needed to structure content in the past need to do so now. Both given content reuse across touchpoints, but also to be able to easily shift your content over to other services as structured data.
So we built Sanity to make this fast and easy while not compromising on the experience for the editor: real-time collaborative work on structured, interlinked data.
BTW – In order to make extending the editing UI clean we've built a system for build-time dependency injection. This gives a non-crufty way to override and compose components: https://www.sanity.io/docs/extending/parts
Looking over your landing page and docs it seems like really thought out product and a lot of effort being put in it. With that being said, I still can't understand the use cases for this. Who are your typical users? What do they use this for?
Sanity isn't a visual programming tool. You can write Sanity applications using JavaScript and whatever tech you want (React, Node.js, etc.).
To provide some background: Your typical modern web application typically revolves around a central CRUD API that you then build apps on top of. You'll typicall have a web app and maybe a native mobile app. But you also need an "admin app" that provides content editing, login, role-based security, and so on.
One option is to use an off-the-shelf CMS. These are almost invariably big, antiquated monoliths that want to be your entire technology stack. Most CMSes not only want to be the system for managing the content, they also want to do the delivery, through some kind of templating system that force you to write your application inside the CMS. I've never met a developer who likes their CMS.
Since CMSes suck so much, companies also very commonly roll their own content management from scratch, which means you spend an awful amount of time writing common stuff unrelated to your core app — database CRUD code, APIs, role-based security, and so on. Rails took off because it was so easy to define your data model and get the CRUD API off the ground. But you still have to do the admin UI; you still have to wire up all those forms, enforce data validation, build complicated things like photo upload and countless other things. And you have to do it all over again for the next app. No admin is reusable.
Sanity turns this upside down; it adopts a "data first" philosophy. First, you get a general-purpose data store for storing your content. It's an advanced document-oriented, transactional data store that comes with live change feeds, strict schema validation, and fine-grained permissions and an expressive query language called GROQ, which is reminiscent of (but different from) GraphQL. This data store replaces your ad-hoc CRUD API.
The second part is the Content Studio. This is a modern, extensible, customizable JavaScript framework that renders a content editing UI on top of the backend data. The UI has been designed from the ground up for the data store, and supports live collaborative, Google Docs-style editing. It's implemented in React.
So with those two building blocks, you get a way to store data and edit it, but Sanity leaves everything else to you. You can use whatever technology stack (Rails, PHP, Django, etc.) to develop your front end apps, as long as you use the data store.
Disclosure: I work on the Sanity open-source data store, called Gradient. However, I'm not directly involved in the Sanity project, so the above is just my personal perspective.
Thanks for this well-written and concise explanation. It took me from "what the hell is this BS" to "oh that makes sense."
I bother with this "thanks" message because I was ready to write a tirade about the technophile echo chamber of nonsense web widgets that seem to show up on HN regularly; solutions in search of problems that should never exist in the first place. Unfortunately, Sanity's website screams "we got some graphics people together to dress up some code we stole and obfuscated from GitHub," instead of "professional solution to a real problem." They should just replace the whole design with your reply here, in plain text. But then I guess it would be far more difficult to convince the CIO to adopt.
There should be some kind of hidden standard file on all these sites that you can go to, like "sanity.io/ACTUAL.txt" or something. It would just give you the actual story of what's happening, and not use words like "touchpoint," nor have 90s Hollywood garbage flying all over the screen. Again, I understand the purpose of the lightshow, but it usually causes me to immediately close the tab. I only stuck around for this because the problem of CMSes sucking is all too real.
Every greenfield project starts with a data model, but eventually gets encumbered in lots of crazy, bespoke business logic. This happens 6 months to 2 years into a project when some person asks for "one little thing". I'd love to see people who have used this for a while talk about data migrations, constraints, and all the other cruft that ends up happening in software development of CRUD.
This reminds me of Microsoft Sharepoint without all the widgets (which is what I meant when I said "visual") or Salesforce or even Microsoft Access. All of which are fairly difficult to manage, but appeal to a certain kind of customer.
The problem comes in when you have some complex business logic (you need 2 levels of approval on a Tuesday to publish this data)
I'd rather write all that stuff in a popular programming language.
While true, any data model is susceptible to cruft, no matter what stack you use.
For complicated rules like your example use case, you can add anything you want to the client-side validation hooks. In fact, almost all data validation currently happens client-side.
It's true that you'd not be able to enforce anything particularly complex if you submit writes directly to the API, but we're planning on supporting webhook-based validation, where you register a webhook that will receive documents for approval. We've successfully used this pattern in past projects. For example, something that isn't easily expressed declaratively is Hacker News' rule that thread comments are only editable a certain amount of time after they're submitted. We, too, prefer this kind of thing to be implemented in code.
Disclosure: I work on the data store, but not on Sanity itself.
I meant specifically when building a CMS. Being able to build a CMS that is multilingual, that can adapt to any form of content and workflow + be easy to use for editors is much harder than implementing the underlying technology.
Of all the fancy overengineered dynamic marketing homepages I've seen, this is by far the best. No scroll-jacking, performant, degrades gracefully, still looks great without JS. Excellently done.
I have a vested interest in this (I work on the open-source data store used internally by Sanity), but I genuinely think Sanity is a game-changer in the CMS space.
What is a "headless CMS" at first place? why do you assume people even understand what it means? I went to your home page I still had no idea what your product is supposed to do.
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.
Congrats on shipping. I went through your docs and it's very clear and comprehensive.
Also love your startup / MVP friendly pricing => https://www.sanity.io/pricing as compared to the other most popular headless CMS (you know who they are!).
graph.cool (I haven't tried scraphold yet) leans more towards being “database editors”; Sanity leans more towards being a CMS. E.g you wouldn't have content editors login to the graph.cool interface to edit content, but with Sanity, that's kinda the point. Sanity's query language (GROQ) is much easier to work with compared to GraphQL (while both are awesome).
It's hard for me to trust services like these that don't provide even a paid self-hosted version. Backend lock-in like Parse, but it probably won't get a community to rewrite it. So good luck if they ever go under.
When I saw the OMA and DS+R logos on your marketing site, I thought no way it's the Architecture firms...prob some niche technology companies in Europe.
But lo and behold, you guys did build their new websites! For the HN crowd, OMA and DS+R are at the top of the field...as a tech analog maybe comparable to Stripe and OpenAI.
I've been diving deep into the finding the right headless CMS and so far have found most either lacking or too expensive (Contentful anyone?). At the moment, hacking away at Netlify's React CMS, but it's a struggle.
Excited to check out your product especially since it's used for architecture firms I love and respect!