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

Zod 4

zod.dev

Post reply on HN
Print view View original

61–70 of 260 posts

Re: Zod 4

#61

Post by owebmaster »

90s_dev wrote: post #30
causal wrote: post #5

Zod is a lot better than some of the alternative solutions I've seen. That said, the need for this sort of explicit validation always felt like a failure of where modern web development has taken us. It's so frustrating how full-stack development requires so many ways of describing the same shapes: JS input validation, Swagger for API definition, server-side input validation, ORM for schema conformance, and TypeScrip…

All APIs are experimental and in a state of constant flux and evolution, including the web. The only time status quo is fine is when it's for clients and employers who just want stuff done and don't care how. In that context, all these unfortunate layers of complexity at least mean more billable hours.

> All APIs are experimental and in a state of constant flux and evolution, including the web.

for better or worse the web only adds, don't change or remove APIs

Re: Zod 4

#62

Post by bjacobso »

satvikpendem wrote: post #36
neilpa wrote: post #4

We're currently evaluating both Zod and ArkType as a replacement for earlier JSON schema validations. The thing I can't get over with Zod is the syntax is _so_ different from defining TS types. Are there reasons to go with Zod over ArkType?

We also chose ArkType after evaluating Zod, Valibot, and Effect Schema, among others. It seemed to have the best developer experience while also being much faster. It also supports the Standard Schema project which I believe Effect Schema does not fully support.

I believe Effect Schema fully supports Standard Schema, the issue is that it supports much more than Standard Schema, so not all schemas will work and thus provide compile time errors.

Re: Zod 4

#63

Post by gejose »

cluckindan wrote: post #3

Between GraphQL and Zod, there really is no comparison. The latter feels clunky and superfluous by design when the former ecosystem can smoothly provide static TS typings without extra work or schema duplication.

Ah yes two totally different technologies - let's compare them like they're designed to solve the exact same problem

Re: Zod 4

#64

Post by iainmerrick »

johnfn wrote: post #45
probabletrain wrote: post #37

Earlier quoted context omitted.

In an ideal world you'd have one source of truth for what the shape of a User could be (which may well be a discriminated union of User and AnonymousUser or similar). Without fullstack TS this could look something like: (for a Python backend) Pydantic models+union for the various shapes of `User`, and then OpenAPI/GraphQL schema generation+codegen for the TS client.

The problem with this is that your One True User shape tends to have a bunch of optional properties on it. e.g., in the user profile you fetch Post[], but in the user directory you don't, and so on with other joined properties. If every endpoint returns the One True User, then you end up needing to write conditional logic to guard against (say) `.posts` when you fetch users in the profile, even though you know that `…

In Typescript at least, if the discriminated union is set up correctly, you just need a single check of the type field. That lets TS narrow the type so it knows whether e.g. `.posts` is present or not.

Re: Zod 4

#65

Post by koakuma-chan »

cscheid wrote: post #52
koakuma-chan wrote: post #38

Earlier quoted context omitted.

> For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Or just use an LLM.

This is the kind of task that LLMs are precisely terrible at; there isn't an abundance of Zod 4 examples, and the LLM will sure as shit will give you _something_ you are now by definition ill-equipped to assess. I'm confident about this assessment because I maintain a large-ish piece of software and perenially have to decipher user reports of hallucinated LLM syntax for new features.

Are you sure that's not a skill issue? Zod v4 has .mdx documentation which can be given to the LLM as context, including a migration guide. A reasoning LLM should be able to manage.

Re: Zod 4

#66

Post by atonse »

satvikpendem wrote: post #22

Zod 4 looks good but even with their latest improvements, ArkType is still an order of magnitude faster. Sometimes for the sake of backward and syntax compatibility, it is difficult to make something much faster than a fully greenfield newer library. We recently did an analysis of all these types of tools for our project and decided to go with ArkType for partially this reason, the other was TypeScript ergonomics fel…

I was looking at all their speed metrics, and can you explain to me where the speed makes a difference?

We only use zod to validate forms, so I keep thinking "how does this matter?" Are people maybe using it to validate high throughput API input messages or something like that, where performance may matter more?

Re: Zod 4

#67

Post by satvikpendem »

bjacobso wrote: post #62
satvikpendem wrote: post #36

Earlier quoted context omitted.

We also chose ArkType after evaluating Zod, Valibot, and Effect Schema, among others. It seemed to have the best developer experience while also being much faster. It also supports the Standard Schema project which I believe Effect Schema does not fully support.

I believe Effect Schema fully supports Standard Schema, the issue is that it supports much more than Standard Schema, so not all schemas will work and thus provide compile time errors.

Yes that's correct, it's more powerful but we wanted to maintain full compatibility just for the future as well. But if you're all in on the Effect ecosystem, it's quite nice.

Re: Zod 4

#68

Post by gavinray »

johnfn wrote: post #20

I'm curious if anyone here can answer a question I've wondered about for a long time. I've heard Zod might be in the right ballpark, but from reading the documentation, I'm not sure how I would go about it. Say I have a type returned by the server that might have more sophisticated types than the server API can represent. For instance, api/:postid/author returns a User, but it could either be a normal User or an anon…

This doesn't help in your case, but this is what GraphQL was invented for.

TS libraries for GQL queries can dynamically infer the response shape from the shape of the selected fields.

Such that the query

    query {
        user {
            username
            posts {
                text
            }
        }
    }
Would be

    type Response = {
        user: {
            username: string
            posts: Array
        }
    }
And a query with just { user { username } } would have the posts property omitted entirely.

Re: Zod 4

#69

Post by satvikpendem »

atonse wrote: post #66
satvikpendem wrote: post #22

Zod 4 looks good but even with their latest improvements, ArkType is still an order of magnitude faster. Sometimes for the sake of backward and syntax compatibility, it is difficult to make something much faster than a fully greenfield newer library. We recently did an analysis of all these types of tools for our project and decided to go with ArkType for partially this reason, the other was TypeScript ergonomics fel…

I was looking at all their speed metrics, and can you explain to me where the speed makes a difference? We only use zod to validate forms, so I keep thinking "how does this matter?" Are people maybe using it to validate high throughput API input messages or something like that, where performance may matter more?

Yes, we use it to validate the API responses from the backend (as well as type validation on the backend itself from any frontend POST requests), and especially on the client side, speed and bundle size is very important.

Re: Zod 4

#70

Post by sesm »

satvikpendem wrote: post #36
neilpa wrote: post #4

We're currently evaluating both Zod and ArkType as a replacement for earlier JSON schema validations. The thing I can't get over with Zod is the syntax is _so_ different from defining TS types. Are there reasons to go with Zod over ArkType?

We also chose ArkType after evaluating Zod, Valibot, and Effect Schema, among others. It seemed to have the best developer experience while also being much faster. It also supports the Standard Schema project which I believe Effect Schema does not fully support.

Does ArkType support generating data from schema?
Post reply on HN