ArkType is a really interesting library that has a difficult time marketing itself. More than being a schema validator, it brings TS types into the runtime, so you can programmatically work with types as data with (near?) full fidelity.<p>I've been evaluating schema libraries for a better-than-Zod source of truth, and ArkType is where I've been focused. Zod v4 just entered beta[1], and it improves many of my problems with it. For such a mature library to improve like this, v4 is treat and speaks volumes to the quality of engineering. But ArkType has a much larger scope, and feels to me more like a data modeling language than a library. Something I definitely want as a dev!<p>The main downside I see is that its runtime code size footprint is much larger than Zod. For some frontends this may be acceptable, but it's a real cost that isn't wise to pay in many cases. The good news is with precompilation[2] I think ArkType will come into its own and look more like a language with a compiler, and be suitable for lightweight frontends too.<p>[1] <a href="https://v4.zod.dev/v4" rel="nofollow">https://v4.zod.dev/v4</a><p>[2] <a href="https://github.com/arktypeio/arktype/issues/810">https://github.com/arktypeio/arktype/issues/810</a>
ArkType looks anything but ergonomic to me. Typescript in strings? Double level type encoding?<p>It’s a miracle it can be 100x faster than Zod, but speed was never my issue with zod to begin with.
In validation, it's never about speed. Is how you relate the schema tree to the error reporting tree. If you didn't already, you will figure that out eventually.<p>If you mess that (either by being too flat, too customizeable or too limited), library users will start coming up with their own wrappers around it, which will make your stuff slower and your role as a maintainer hell.<p>(source: 15 years intermittently maintaining a similar project).<p>There is an obvious need for a validation library nowadays that bridges oop, functional and natural languages. Its value, if adopted as a standard, would be immense. The floor is still lava though, can't make it work in today's software culture.
Really conflicted with TS. On one hand it’s so impressive that a type system can do these sort of tricks. On the other hand if we had type introspection at runtime we wouldn’t need any of this.
V4 of zod landed recently and it promises better perf <a href="https://v4.zod.dev/v4" rel="nofollow">https://v4.zod.dev/v4</a>
Since recent typescript features have made it more possible, I’m less interested in runtime validation, and really only keen in build-type schema validation.<p>There’s a few tools out there that generate code that typescript will prove will validate your schema. That I think is the path forward.
With many TS features making their way into JS, I've sometimes wondered if TS is to JS what Sass is to CSS. I currently rely on TS, but I now consider Saas harmful [there being overlapping syntax w/ vanilla CSS].
I like the idea of having types at runtime for parsing etc and generating validators in various languages. What stopped me from going there so far is that I already have TypeScript types provided for the various libraries I use. How good are the tools for importing TypeScript types into ArkType/Zod and working with types in various representations in parallel?
This looks interesting, however Zod has become a standard of sorts and a lot of libraries I use expect, for example, a JSON schema defined as a Zod schema. I would need some sort of adapter to a Zod schema to make this work for me.
Is this at all related to Huawei's ArkTS?<p><a href="https://developer.huawei.com/consumer/en/doc/harmonyos-guides-V14/arkts-overview-V14" rel="nofollow">https://developer.huawei.com/consumer/en/doc/harmonyos-guide...</a>
TS: "We have added types to javascript, everything is now strongly typed, and the compiler will pester you to no end until it's happy with the types."<p>Me: "Awesome, so I get an object from an API, it will be trivial to check at runtime if it's of a given type. Or to have a debug mode that checks each function's inputs to match the declared types. Otherwise the types would be just an empty charade. Right?"<p>TS: "What?"<p>Me: "What?"<p>Realizing this was a true facepalm moment for me. No one ever thought of adding a debug TS mode where it would turn<p>function myFunc(a: string, b: number) {}<p>into<p>function myFunc(a: string, b: number) {
assert(typeof a === "string")
assert(typeof b === "number")
}<p>to catch all the "somebody fetched a wrong type from the backend" or "someone did some stupid ((a as any) as B) once to silence the compiler and now you can't trust any type assertion about your codebase" problems. Nada.