ArkType: Ergonomic TS validator 100x faster than Zod • Hacker News Board

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

#41

Post by BoorishBears » Sun, Apr 13, 2025, 2:39 AM UTC

gajus wrote: post #35

epolanski wrote: post #18

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…

Zod is the default validator for https://github.com/gajus/slonik . Zod alone accounts for a significant portion of the CPU time.

> In the context of the network overhead, validation accounts for a tiny amount of the total execution time.

> Just to give an idea, in our sample of data, it takes sub 0.1ms to validate 1 row, ~3ms to validate 1,000 and ~25ms to validate 100,000 rows.

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

#42

Post by your_fin » Sun, Apr 13, 2025, 3:03 AM UTC

domoritz wrote: post #5

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?

The way zod and arktype generally handle this is by providing treating the schema as the source of truth, rather than a type. They then provide a way to define the type in terms of the schema:

  // zod 3 syntax
  import { z } from 'zod'

  const RGB = z.schema({
    red: z.number(),
    green: z.number(),
    blue: z.number(),
  })
  type RGB = z.infer
  // same thing as:
  // type RGB = { red: number; green: number; blue: number };

For the initial migration, there are tools that can automatically convert types into the equivalent schema. A quick search turned up https://transform.tools/typesgcript-to-zodghl, but I've seen others too.

For what it's worth, I have come to prefer this deriving types from parsers approach to the other way around.

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

#43

Post by Escapado » Sun, Apr 13, 2025, 3:06 AM UTC

epolanski wrote: post #18

Chyzwar wrote: 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…

Yup, maintained an e-commerce site where the products were coming from a third party api and the products often had 200+ properties and we often needed certain combinations of them to be present to display them. We created schemas for all of them and also had to transform the data quite a bit and used union types extensively, so when displaying a product list with hundreds of these products, Zod would take some time(400+ ms) for parsing through that. Valibot took about 50ms. And the editor performance was also noticeably worse with Zod, taking up to three seconds for code completion suggestions to pop up or type inference to complete - but truth be told valibot was not significantly better here at the time.

I agree though, that filling your website with tracking crap is a stupid idea as well.

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

#44

Post by CharlieDigital » Sun, Apr 13, 2025, 3:07 AM UTC

surprisedcat wrote: post #40

CharlieDigital wrote: post #33

Earlier quoted context omitted.

I recently went down this same rabbit hole for backend and stumbled on Typia[0] and Nestia[1] from the same developer. The DX with this is fantastic , especially when combined with Kysely[2] because now it's pure TypeScript end-to-end (no runtime schema artifacts and validations get AOT inlined). I was so shocked by how good this is that I ended up writing up a small deck (haven't had time to write this into a doc ye…

Thanks for sharing the deck! I had no idea Typia existed and it looks absolutely amazing. I guess I'll be trying it out this weekend or next :)

The docs have a bit of a rough edge because the author is Korean, but the examples are quite good and took me maybe 2-3 hours to work through.

Once everything clicked (quite shortly in), I was a bit blown away by everything "just working" as pure TypeScript; I can only describe the DX as "smooth" compared to Zod because now it's TypeScript.

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

#45

Post by eyelidlessness » Sun, Apr 13, 2025, 3:09 AM UTC

madeofpalk wrote: post #23

root_axis wrote: post #13

Earlier quoted context omitted.

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 neve…

The thing that makes libraries like Zod trustworthy is that they:

- parse as their validation mechanism

- compose small units (close to the type system’s own semantics for their runtime equivalents, trivially verifiable), with general composition semantics (also close to the type system), into larger structures which are (almost) tautologically correct.

Obviously there’s always room for some error, but the approach is about as close to “safe” as you can get without a prover. The most common source of error isn’t mistakes in the underlying implementation but mistakes in communicating/comprehending nuances of the semantics (especially where concepts like optionality and strictness meet concepts like unions and intersections, which are also footguns in the type system).

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

#46

Post by anon3459 » Sun, Apr 13, 2025, 3:14 AM UTC

epolanski wrote: post #18

Chyzwar wrote: 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…

My issue is ts server perromance not so much runtime

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

#47

Post by t1amat » Sun, Apr 13, 2025, 3:22 AM UTC

your_fin wrote: post #42

domoritz wrote: post #5

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?

The way zod and arktype generally handle this is by providing treating the schema as the source of truth, rather than a type. They then provide a way to define the type in terms of the schema: // zod 3 syntax import { z } from 'zod' const RGB = z.schema({ red: z.number(), green: z.number(), blue: z.number(), }) type RGB = z.infer // same thing as: // type RGB = { red: number; green: number; blue: number }; For the in…

With Zod you can build a schema that would match an existing type. Typescript will complain if the schema you build does not match the type you are representing, which is helpful. From memory:

  import { z } from ‘zod’

  type Message = { body: string; }

  const messageSchema: z.Type = z.object({ body: z.string() })

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

#48

Post by t1amat » Sun, Apr 13, 2025, 3:30 AM UTC

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.

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

#49

Post by Aeolun » Sun, Apr 13, 2025, 4:07 AM UTC

ArkType looks anything but ergonomic to me. Typescript in strings? Double level type encoding?

It’s a miracle it can be 100x faster than Zod, but speed was never my issue with zod to begin with.

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

#50

Post by e1g » Sun, Apr 13, 2025, 4:51 AM UTC

alganet wrote: post #37

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. 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. (source: 15 years intermittently mainta…

Especially when unions are involved. We have a flexible schema for many parameters (e.g., X accepts an object or an array of them, and one object has some properties that could be an enum or a detailed shape), and both Zod and Valibot produce incomprehensible and useless error messages that don’t explain what’s wrong. We had to roll our own.