Live data from Hacker News

ArkType: Ergonomic TS validator 100x faster than Zod

arktype.io

21–30 of 72 posts

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#21

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. 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 w…

> it brings TS types into the runtime So...it's a parser. Like Zod or effect schema. https://effect.website/docs/schema/introduction/

No, it's more like a type reflection system, at least as I understand it. You can use it to parse types, but you can also do a lot more than that.

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#22

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

Which typescript features are improving runtime validation?

Previously (~2-3 years ago), it was impossible to narrow `unknown` to a fully typed object. Recently-ish, they added the ability for `"foo" in obj` to type-refine `object` to `object & {"foo": unknown}`, which lets you further narrow foo down to something more specific.

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#23

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

Runtime validation is strictly necessary across data boundaries that consume user input.

Sorry, I was unclear.

Using a library like zod requires you to trust that Zod will correctly validate the type. Instead, I much prefer to have schema validation code that typescript proves will work correctly. I want the build-type checks that my runtime validation is correct.

Typia generates runtime code that typescript can check correctly validates a given schema https://typia.io/docs/validators/assert/ . I've never actually used it, but this is closer to the realm I prefer.

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#24
post #21

Earlier quoted context omitted.

> it brings TS types into the runtime So...it's a parser. Like Zod or effect schema. https://effect.website/docs/schema/introduction/

No, it's more like a type reflection system, at least as I understand it. You can use it to parse types, but you can also do a lot more than that.

Could you give an example or two of “more than that”?

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#25
post #3

V4 of zod landed recently and it promises better perf https://v4.zod.dev/v4

I really want to see the people that have performance issues with Zod and what's their use case. I mean it. I've been parsing (not just validating) runtime values from a decade (io-ts, Zod, effect/schema, t-comb, etc) and I find the performance penalty irrelevant in virtually any project, either FE or BE. Seriously, people will fill their website with Google tracking crap, 20000 libraries, react crap for a simple cru…

I’ve used it on the backend to validate and clean up tens of thousands of documents from Elasticsearch queries, and the time spent in Zod was very much noticeable

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#26
post #9

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. 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 w…

Definitely check out Valibot as well, it may be the smaller footprint zod you’re looking for: https://valibot.dev

There's also zod mini now too https://v4.zod.dev/packages/mini

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#27
post #24
post #21

Earlier quoted context omitted.

No, it's more like a type reflection system, at least as I understand it. You can use it to parse types, but you can also do a lot more than that.

Could you give an example or two of “more than that”?

Yeah, you can walk the AST of your types at runtime and do arbitrary things with it. For example, we're using ArkTypes as our single source of truth for our data and deriving database schemas from them.

This becomes very nice because ArkType's data model is close to an enriched version of TypeScript's own data model. So it's like having your TypeScript types introspectable and transformable at runtime.

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#29
post #6

Earlier quoted context omitted.

> The main downside I see is that its runtime code size footprint is much larger than Zod. Yes, it unfortunately really does bloat your bundle a lot, which is a big reason I personally chose to go with Valibot instead (it also helps that it's a lot closer to zods API so it's easier to pickup). Thanks for linking that issue, I'll definitely revisit it if they can get the size down.

Personally, I find Zod’s API extremely intimidating. Anything more resembling TypeScript is way better. ArkType is neat, but ideally we’d have something like: export reflect type User = { id: number; username: string; // ... }; Edit: just remembered about this one: https://github.com/GoogleFeud/ts-runtime-checks

It's not perfect and doesn't cover all of zods functionality (iirc coercion) but I've used https://www.npmjs.com/package/ts-to-zod before to generate zod schemas directly from types.

Re: ArkType: Ergonomic TS validator 100x faster than Zod

#30

Earlier quoted context omitted.

I really want to see the people that have performance issues with Zod and what's their use case. I mean it. I've been parsing (not just validating) runtime values from a decade (io-ts, Zod, effect/schema, t-comb, etc) and I find the performance penalty irrelevant in virtually any project, either FE or BE. Seriously, people will fill their website with Google tracking crap, 20000 libraries, react crap for a simple cru…

We use it heavily for backend code, and it is a bit of a hot path for our use cases. However the biggest issue is how big the types are by default. I had a 500 line schema file that compiled into a 800,000 line .d.ts file — occupying a huge proportion of our overall typechecking time.

That sounds absolutely absurd.

Are you using a lot of deeply nested objects + unions/intersections?

Post reply on HN