Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ArkType: Ergonomic TS validator 100x faster than Zod

arktype.io

Post reply on HN
Print view View original

51–60 of 72 posts

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

#51

Post by retropragma »

CharlieDigital wrote: post #33
webdevladder wrote: post #2

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…

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…

An interesting development with Typia is that it will need to be rewritten in Go to work with TypeScript 7. https://github.com/samchon/typia/issues/1534#issuecomment-27...

This is because it relies on patching the TypeScript implementation. I'm curious if its approach is even feasible with Go?

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

#52

Post by retropragma »

udbhavs wrote: post #36
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…

I was going to ask about how pure types would fill the gap for other validations in Zod like number min/max ranges, but seeing the tags feature use intersection types for that is really neat. I tried assigning a `string & tags.MinLength ` to a `string & tags.MinLength ` and it's interesting that it threw an error saying they were incompatible.

That's because "minimum length" cannot be enforced in TypeScript. Maybe you already know this.

I'm not a Typia user myself, but my RPC framework has the same feature, and the MinLength issue you mentioned doesn't crop up if you only use the type tags at the client-server boundary, which is enough in my experience.

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

#53

Post by retropragma »

mintplant wrote: post #27
vosper wrote: post #24

Earlier quoted context omitted.

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.

TypeBox is similar by virtue of its goal of its runtime types matching JSON Schema's data model without need for conversion.

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

#54

Post by retropragma »

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…

I find your last paragraph to be lacking. Would help if you elaborated more on the purported need for this "bridge" concept.

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

#55

Post by thiht »

Aeolun wrote: post #49

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.

I have to agree, I know not all people like the same things, but this looks terrible to me. Maybe it’s like Tailwind in the sense that you learn to like it when you actually use it.

The thing is Zod seems fairly standard in the ecosystem, and I value that more than novelty.

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

#56

Post by epolanski »

mintplant wrote: post #27
vosper wrote: post #24

Earlier quoted context omitted.

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.

You can do whatever you want with the AST in effect schema too, it's a parser with a decoder/encoder architecture:

https://effect.website/docs/schema/transformations/

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

#57

Post by snafferty »

retropragma wrote: post #51
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…

An interesting development with Typia is that it will need to be rewritten in Go to work with TypeScript 7. https://github.com/samchon/typia/issues/1534#issuecomment-27... This is because it relies on patching the TypeScript implementation. I'm curious if its approach is even feasible with Go?

Between this and node adding the --experimental-strip-types option which would otherwise allow people to skip compilation, I'm not sure I would choose Typia right now. I'm sure it's a great library, but these don't bode well for its future.

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

#58

Post by davnicwil »

Aeolun wrote: post #49

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.

I've not tried it yet so am reserving judgement, but it doesn't look that bad at all.

Heads up, seems overall more scannable than an equivalent zod schema though given the similarity to 'raw' TS.

Also it seems like a fairly short hop to this engine being used with actual raw TS types in a compilation step or prisma-style codegen?

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

#59

Post by CharlieDigital »

retropragma wrote: post #51
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…

An interesting development with Typia is that it will need to be rewritten in Go to work with TypeScript 7. https://github.com/samchon/typia/issues/1534#issuecomment-27... This is because it relies on patching the TypeScript implementation. I'm curious if its approach is even feasible with Go?

I think it's fair to be skeptical, but I'm aligned with the overall approach the author took and I think the approach itself is what is interesting (pure TS + AOT).

Author + contributors and ts-patch team[0] seem up for a rewrite in Go based on that thread! Might be bumpy, but a pure TS approach is really appealing. I'm rooting for them :)

[0] https://github.com/nonara/ts-patch/issues/181#issuecomment-2...

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

#60

Post by tomaskafka »

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

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?"

TS: "What?"

Me: "What?"

Realizing this was a true facepalm moment for me. No one ever thought of adding a debug TS mode where it would turn

function myFunc(a: string, b: number) {}

into

function myFunc(a: string, b: number) { assert(typeof a === "string") assert(typeof b === "number") }

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.

Post reply on HN