349 karma · joined November 14, 2017
Happy to answer questions, and I'll pull in the author for anything I can't.
The thing that prompted this: I kept having conversations with teams where the first question was "how do we write better skills files?" and I kept finding that the issues were upstream in our error messages, CLI surface, and so on. I increasingly feel that Skill files is your "last resort."
The Workbench experiment in the post is admittedly simplified to unpack the mental model; you would probably set up evals etc to actually test it, which we have started doing at Sanity as well.
Happy to answer questions and channel more of our experience with agents (heh) and designing for them.
Rosti's approach uses three things: proportional normalization based on aspect ratio, pixel density analysis (so a dense wordmark doesn't visually overpower a thin logomark), and a center-of-mass calculation for optical alignment. The perceptual sizing math builds on Dan Paquette's earlier work.
The core normalization logic is plain JS with no React dependency: https://github.com/sanity-labs/react-logo-soup/blob/main/src...
Someone already forked it into a framework-agnostic version: https://github.com/auroris/logo-soup
Rosti is around if there are questions about the density compensation or optical alignment math.
The core formula is Dan Paquette's proportional normalization (aspect ratio raised to a scale factor), but the density compensation and visual center-of-mass calculation are the interesting additions.
The visual center algorithm weights each pixel by sqrt(colorDistance) * (alpha / 255) to find where the "ink" actually lives vs. the geometric center. It's a subtle effect but makes a noticeable difference with asymmetric logos.
Library is MIT licensed: https://github.com/sanity-labs/react-logo-soup
Live Storybook: https://react-logo-soup.sanity.dev
Working on getting Rosti signed up to HN for questions you might have!
And if you only knew how much those headings and the structure of this post changed as I wrote it out and got internal feedback on it ^^_
My thinking was that it became public pretty quickly once your post went viral (folks were already connecting the dots in the replies), and it felt awkward to respond to the substance without being direct about the context.
But you're right that a heads-up would have been the better move.
I am a marketer and a developer. But I also know that you don't get far by trying to trick people into your product. As a marketer, I also get front row seat seeing how software plays out for a lot of businesses out there, and I have done so for a lot of years. I wanted to share those perspectives in response to Lee's write-up.
So yes, obviously both these pieces make a case for how the software we're employed by solves problems. And anyone who has been in developer marketing for a while knows that the best strategy is to educate and try to do so with credibility.
I don't know folks... Maybe I have been dabbling so much with AI the last couple of years that I have started taking on its style.
I had my digits on the keyboard for this piece though.
But in that bias is a ton of experience in the CMS field and a lot of observation of actual teams trying to solve for content operations challenges. I think that's valuable to share, even if we happen to also sell a solution to these things.
What Apple seems to be doing with Notes—embracing Markdown syntax but not treating it as a source format—feels like a pragmatic move. It acknowledges Markdown’s familiarity without overcommitting to it as a canonical format. That distinction matters: many people like typing emphasis or `code`, but few need or want to version-control or export that exact syntax. It’s the gesture of Markdown that carries value for most users, not the fidelity to a plain-text artifact. "Even" Google Docs implemented it recently.
In my article, I argue that Markdown is increasingly a “source language” for interfaces, not documents, and this Apple Notes move seems to align with that trend. Curious how others feel about Markdown as an authoring experience vs. a content format.
Source: https://bsky.app/profile/even.westvang.com/post/3laob7tefxk2...
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.
Would love to learn more about:
* 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?
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.
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.
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.
Sanity.io is the fastest, most flexible platform for delivering content to digital devices and products. Our platform is redefining the CMS market and changing the way organizations collaborate and work with content. We’re hosting a real-time API for structured content, an open-source editing environment built with React. We’re also building tooling for GROQ (a general query language for JSON), GraphQL, and portabletext.org.
We are growing fast, and are looking for a range of roles:
> Sr. Front-End Web Developer
> Full Stack Developer
> Solution Engineer
> Full-stack developer, Integrations
> Support Engineer
And more!
Go to https://www.sanity.io/careers
We are a Series A company backed by Threshold Ventures, Ev Williams and more. We’re based in San Francisco and Oslo, running a remote friendly team setup.
Sanity.io is the fastest, most flexible platform for delivering content to digital devices and products. Our platform is redefining the CMS market and changing the way organizations collaborate and work with content. We’re hosting a real-time API for structured content, an open-source editing environment built with React. We’re also building tooling for GROQ (a general query language for JSON), GraphQL, and portabletext.org.
We are growing fast, and are looking for a range of roles:
> Sr. Front-End Web Developer
> Full Stack Developer
> Solution Engineer
> Support Engineer
And more!
Go to https://www.sanity.io/careers
We are a Series A company backed by Threshold Ventures, Ev Williams and more. We’re based in San Francisco and Oslo, running a remote friendly team setup.