[HN Gopher] ArkType: Ergonomic TS validator 100x faster than Zod
___________________________________________________________________
ArkType: Ergonomic TS validator 100x faster than Zod
Author : nathan_phoenix
Score : 90 points
Date : 2025-04-12 16:01 UTC (6 hours ago)
(HTM) web link (arktype.io)
(TXT) w3m dump (arktype.io)
| webdevladder wrote:
| 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 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!
|
| 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.
|
| [1] https://v4.zod.dev/v4
|
| [2] https://github.com/arktypeio/arktype/issues/810
| worble wrote:
| > 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.
| notpushkin wrote:
| 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
| ChocolateGod wrote:
| 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.
| sync wrote:
| Definitely check out Valibot as well, it may be the smaller
| footprint zod you're looking for: https://valibot.dev
| Jaydenaus wrote:
| There's also zod mini now too
| https://v4.zod.dev/packages/mini
| epolanski wrote:
| > it brings TS types into the runtime
|
| So...it's a parser. Like Zod or effect schema.
|
| https://effect.website/docs/schema/introduction/
| MrJohz wrote:
| 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.
| vosper wrote:
| Could you give an example or two of "more than that"?
| mintplant wrote:
| 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.
| Chyzwar wrote:
| V4 of zod landed recently and it promises better perf
| https://v4.zod.dev/v4
| re-thc wrote:
| > V4 of zod landed recently and it promises better perf
|
| Still far behind if the 100x is to be believed. v4 isn't even a
| 10x improvement. Nice changes though.
| epolanski wrote:
| 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?
| andrewingram wrote:
| 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.
| shortcord wrote:
| That sounds absolutely absurd.
|
| Are you using a lot of deeply nested objects +
| unions/intersections?
| andrewingram wrote:
| A fair number of unions, yeah. Which also means some of
| the tricks for keeping the types small don't work --- ie
| taking advantage of interface reuse.
| vosper wrote:
| 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
| madeofpalk wrote:
| 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.
| dkubb wrote:
| I don't know too much about about the TS ecosystem but do these
| new systems you talk about do it via a "Smart Constructor"?
| That is the pattern I typically use to solve this problem in
| Haskell and Rust code.
| seniorsassycat wrote:
| Which typescript features are improving runtime validation?
| madeofpalk wrote:
| 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.
| root_axis wrote:
| Runtime validation is strictly necessary across data boundaries
| that consume user input.
| madeofpalk wrote:
| 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.
| esafak wrote:
| Any good article about these features?
| domoritz wrote:
| 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?
| chrisweekly wrote:
| 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].
| cendyne wrote:
| I'd be very interested in how to replicate parsing like this.
| Slow typescript inference has stalled my own exploration into
| things like this.
| cugul wrote:
| Is this at all related to Huawei's ArkTS?
|
| https://developer.huawei.com/consumer/en/doc/harmonyos-guide...
| KTibow wrote:
| No.
| brap wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-12 23:00 UTC)