
Show HN: Sanity – A Headless CMS Construction Kit in JavaScript - rexxars
https://www.sanity.io/
======
moeamaya
Architect + Technologist here.

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!

~~~
evenw
Thank you! We so enjoyed those projects. Do get in touch if you have any
questions on your excursion! There's a public Gitter
([https://gitter.im/sanity-io/sanity](https://gitter.im/sanity-io/sanity)) and
I'm @even ([https://twitter.com/even](https://twitter.com/even)).

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

Maybe we need a new word.

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

~~~
tarr11
I don't know that I like "data first".

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.

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

------
DavidPP
THe value would in the "Studio" app which is the hardest portion to replicate
(if it's well done).

But I would prefer paying a license for the SDK and host the API myself than
having to rely on a third party for something so crucial to a business.

~~~
kmelve
Well, it has got some real time data syncing stuff going on (which gives it
Google Docs capabilities), I don't think that is trivial to do yourself.

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

~~~
kmelve
Yeah, sorry for misreading you. That's indeed a good point (although both
things are hard ^^_).

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

------
lobster_johnson
Congrats to the Sanity team on launching!

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.

~~~
johnhenry
What data store do you work on?

~~~
lobster_johnson
It's called Gradient. It's not _quite_ ready to be talked about, but we're
very close.

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

I went to the docs:

[https://www.sanity.io/docs/introduction/why-
headless](https://www.sanity.io/docs/introduction/why-headless)

I still have no idea why you call your product "headless CMS".

~~~
svale
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:

[http://oma.eu/projects/timmerhuis](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.

------
0xCMP
Love this. I was on my way to build some kind of version of this.

I'm hoping that there will be documentation on how to self-host the backend
soon as a backup.

------
justboxing
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](https://www.sanity.io/pricing) as compared to
the other most popular headless CMS (you know who they are!).

------
simplify
How does this compare to [https://www.graph.cool/](https://www.graph.cool/) or
[https://scaphold.io/](https://scaphold.io/) ?

~~~
kmelve
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).

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

~~~
tmikaeld
Even if it where open source, it just as well be abandoned if the company
tanks (Like Rubedo CMS).

There's an open source headless CMS here:
[https://getdirectus.com/](https://getdirectus.com/)

It doesn't have all of the batteries of Sanity and uses normal SQL for data
backend, but it's a good way there.

------
pzk1
How does this compare with Directus CMS?

