Zod has the same "simultaneously create schema and types and the process of doing so is pleasant" feature, it's just not using JSON Schema for it (and has more power than JSON schema does).
In the Zod world, if you need JSON Schema to e.g. communicate to the outside world, you can extract it from the Zod schema with https://github.com/StefanTerdell/zod-to-json-schema -- but if you don't, you don't.
JSON Schema is kind of underpowered for real validation, so if you limit yourself to it, then you'll just have a another round of validation immediately after. TypeBox'
s CreateType seems to be the same idea, it cannot be expressed in just JSON Schema.
I think Colin's a rad programmer, he works on EdgeDB which is absolutely my favorite datastore I've ever used and I think Zod's fine if you want to use it. But I don't agree with your premise. I don't, in practice, find the way Zod asks you to think about data compelling. It's probably because I think specifically in communication between systems; making the particulars of the interchange format central to the act of writing the thing, for me, keeps top-of-mind the necessity of both ends having an identical understanding of the allowable semantics. (Similarly, I've never used any Typebox features that don't map to JSON Schema, and I've never felt the need to.)
In the Zod world, if you need JSON Schema to e.g. communicate to the outside world, you can extract it from the Zod schema with https://github.com/StefanTerdell/zod-to-json-schema -- but if you don't, you don't.
JSON Schema is kind of underpowered for real validation, so if you limit yourself to it, then you'll just have a another round of validation immediately after. TypeBox' s CreateType seems to be the same idea, it cannot be expressed in just JSON Schema.