You could actually always host the Studio yourself, since it's an SPA. What's new is that we refactored it out of its custom webpack tooling and made it “just a React dependency” which allows you to embed it into other applications.
It's true that the Studio connects to the hosted data store (<pitch>but as many free projects as you want with pay-as-you-go for overages</pitch>), so the use case is the optionality to have your content workspace with your content models close to where you're consuming it. It also allows you to put the content workspace on a route so that content creators can go to a `/admin` or similar to edit content.
* What you find finicky with installing basic components
* What SEO issues that are connected to using GROQ/TypeScript
As far as I can gather from the docs, Payload doesn't come with more out-of-the-box components, and doesn't support custom blocks in the rich text editor, unless you commit to building the UI for it yourself?
Knut from Sanity.io here. First of all, congrats on the launch and what seems to be a well done product!
And to be a bit nit-picky and to clarify our world-view: The API side of Sanity isn't 3rd-party (it's native to the platform), but it is hosted and propertary.
There are always trade-offs, so no, you don't get the kind of control you get when you host your own Express-server or sit on your own MongoDB instance, but then again, you don't have to do those things to have a scalable real-time document store that supports deeply nested document structures with queryable references (with referential integrity). We build our APIs specifically to improve developer experience where we take care of the hard parts™ so that you can focus on the productive things. All of our HTTP APIs are versioned, because we specifically want to avoid breaking changes as much as possible.
Furthermore, there are other things that you just get. Like GROQ which is way more expressive and flexible for querying data compared to GraphQL (which we also offer). You get on-demand image transforms. You get both content and assets behind a CDN. You have a mutation/patch API that can do transactions with pretty specific operations (“change only this value in an nested array for this key if it matches this value”). Since the backand has full attributed revision history, you can also have controls that prevents race conditions, so that you can programatically update documents even if people are editing them. You can define triggers for webhooks and its payload with GROQ, so you can use serverless functions (or a server) to update content based on conditions. You can hit the export API endpoint and get all of your stuff over a stream wherever you want it. And so on and so forth.
Of course, there are always use cases where you want a solution that can be run fully on-prem or specific bespoke behavior in the database/API-layer beyond the capabilities in the platform. If you need those things, then you should probably look elsewhere than Sanity.io, and Payload might be an excellent choice.
Thanks for these links! I tried to track the origin down, but there's only so much digging one could do. But I think it safe to say that Jekyll _popularlized_ the YAML-style frontmatter.
Markdown is for writing not for editing. If you want to focus on writing, text, and content instead of on bells and whistles with formatting and typesetting it's really hard to go easier than Markdown.
That's exactly my argument. I literally quote Gruber on it.
I'm kinda bummbed out that the post read as an ad. I was super nervous to publish this because it I knew I was poking at something that's near and dear to a lot of devs (myself included). But I have experienced enough friction with Markdown in the real world and wanted to explore poking what I see as the status quo. And it seems to have sparked some conversation, which was what I wanted. I'm truly not trying to “hawk” something, but I believe the thinking that went into Portable Text can provide value and I'm sort of putting it out there for people to make up their own minds.
To your point: I agree, Markdown is for writers, but only for some writers. Maybe I didn't get that across, but it is kinda amazing that it has become so ubiquotos in all its shapes and colors.
But it comes with these actual constrains and challenges that I feel a lot of developers aren't really being upfront or honest about. The simplicity comes with trade-offs that just adds complexity elsewhere. Either for people who don't desire to learn specialized syntax or developers who have to spend a lot of time figuring out how to parse it in a sensible manner to get their job done.
Thanks for taking the time to engage. And I want to be clear, I think Portable Text could be something really excellent for it’s intended use case. I guess I just see that as fundamentally at odds with what Markdown is. I understand your point that Markdown is often used in place it probably shouldn’t be, but I still think we’re talking about two different problems. For me, it isn’t that something like Portable Text doesn’t have a place, it’s that I don’t think it is best compared to something like Markdown.
I agree we should do a better job of showing what options are best for certain scenarios, but I feel like someone making a decision to adopt a really customized version of Markdown needs a different sort of intervention/push to a more desirable format (maybe Portable Text) than the people that actively choose Markdown BECAUSE it is a readable syntax for crafting HTML and their goal is to write HTML in a readable way.
Yeah, I'm well aware that markdown didn't happen in a vacuum and was inspired by plain text formatting conventions. But there is only that much you can cover in an already too long blog post. It wouldn't have changed my argument much either. It wouldn't be historically accurate to say that Markdown existed before Gruber/Swartz, like it wouldn't be accurate to say that HTML existed before Tim-Berners Lee, even though SGML and such was a thing.
I'm not arguing for a more proprietary binary word processor format either. Or that we should type JSON. It's actually possible to have decent WYSIWYG editors that does their job. And they won't get better if don't put our minds to them.
The point you're missing in this reply is the legitime user-unfriendly experience of markdown and the challenges it poses for developers who are trying to solve things for their teams and customers today.
I'll admit that a lot of users don't like it. And maybe someday there will be a WYSIWYG editor that lives up to the name. But after about 30 years of dealing with ones that don't, I might be a little jaded. Plain text conventions like Markdown may not be fancy, but they do at least work.
As the “humanities tecnologist” in question, I'd say that looking at technology as a result of and embedded in human history and culture can be quite interesting and you might even learn something from it. But of course, you could also read and relate to the argument on its own merits?
The article is the opposite of what markdown strives for - waffling on and awful formatting.
Markdown is good because its simple, and has all the required formatting tags required to communicate information succinctly, and is not desirable for people who prefer formatting over content.
Hi, the author here! This is a misrepresentation of my argument. I'm not interested in locking you in at all, I'm actually arguing for the opposite. It doesn't even have to be JSON.
You could actually always host the Studio yourself, since it's an SPA. What's new is that we refactored it out of its custom webpack tooling and made it “just a React dependency” which allows you to embed it into other applications.
It's true that the Studio connects to the hosted data store (<pitch>but as many free projects as you want with pay-as-you-go for overages</pitch>), so the use case is the optionality to have your content workspace with your content models close to where you're consuming it. It also allows you to put the content workspace on a route so that content creators can go to a `/admin` or similar to edit content.