Live data from Hacker News

ArkType: Ergonomic TS validator 100x faster than Zod

arktype.io

11–20 of 72 posts

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

#11

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?

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

#13

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.

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

#15

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.

Any good article about these features?

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

#16
post #6

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…

> 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

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

#17

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/

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

#18
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 crud, and then complain about ms differences in parsing?

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

#20
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…

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.
Post reply on HN