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.
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.