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

Zod v4 Beta

v4.zod.dev

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Zod v4 Beta

#41

Post by alecmev »

iainmerrick wrote: post #19
adriancooney wrote: post #16

Zod is installed in nearly every project I use. It’s an essential part of my toolkit. I adore this library. It near perfect as-is and these additions make it even better. Thanks for all the hard work.

I used to use Zod until I realised it’s rather big (for many projects this isn’t an issue at all, but for some it is). Now I use Valibot which is basically the same thing but nice and small. I do slightly prefer Zod’s API and documentation, though. Edit to add: aha, now I read further in the announcement, looks like @zod/mini may catch up with valibot -- it uses the same function-based design at least, so unused code…

Though exciting, looks like there's still room for shrinkage, the linked article puts a bare-minimum gzipped @zod/mini at 1.88kb, while Valibot is at 0.71kb [1].

[1] https://github.com/anatoo/zod-vs-valibot

Re: Zod v4 Beta

#42

Post by __jonas »

cianuro_ wrote: post #29

I completely understand TypeScript, Zod not so much. The context here is performance. My understanding is that Zod performs synchronous operations to validate the schemas. Something about "using the tool correctly" resonates here. Maybe don’t validate very large and nested schemas frequently and things like that. But I can’t help but think it is adding another layer of potential footguns that you have to be mindful a…

Maybe I'm misunderstanding some aspect here, but it seems to me there are two choices for handling external data in TypeScript:

Either you parse / validate incoming data at an API boundary with a tool like zod, or you do not, and just trust that the data matches the exact shape you expect, opening yourself up to completely unexpected errors / behaviors if it does not.

The latter is probably a decent option if you fully control all components back to front, but if you really value type safety, the former seems like the way to go?

Re: Zod v4 Beta

#43

Post by simjnd »

move-on-by wrote: post #3

I only use Zod in a single library, so my experience with it is pretty minimal. One thing I have really enjoyed with it is the low maintenance. So, when I saw this post and read the first few paragraphs, I was filled with dread for having to do yet another major dependency update. Reading of all the improvements- surly the ‘breaking changes’ list must be massive. Having read the full article, it seems like the breaki…

Even if the breaking changes were massive, you could keep the dependency pinned at the version you're using and not upgrade if the new features aren't useful/compelling

Re: Zod v4 Beta

#45

Post by cianuro_ »

__jonas wrote: post #42
cianuro_ wrote: post #29

I completely understand TypeScript, Zod not so much. The context here is performance. My understanding is that Zod performs synchronous operations to validate the schemas. Something about "using the tool correctly" resonates here. Maybe don’t validate very large and nested schemas frequently and things like that. But I can’t help but think it is adding another layer of potential footguns that you have to be mindful a…

Maybe I'm misunderstanding some aspect here, but it seems to me there are two choices for handling external data in TypeScript: Either you parse / validate incoming data at an API boundary with a tool like zod, or you do not, and just trust that the data matches the exact shape you expect, opening yourself up to completely unexpected errors / behaviors if it does not. The latter is probably a decent option if you ful…

Yes, I agree. Some sort of check has to happen somewhere to validate the incoming payload. If you’re looking for type safety, it makes sense to use Zod for this.

To me it is bending the original tool (JS, async driven, weak typing) to fit a purpose it was not made for (hard typing, synchronous) in detriment of what it is that makes the tool good in the first place (IO performance).

Re: Zod v4 Beta

#46

Post by shepherdjerred »

cianuro_ wrote: post #45
__jonas wrote: post #42

Earlier quoted context omitted.

Maybe I'm misunderstanding some aspect here, but it seems to me there are two choices for handling external data in TypeScript: Either you parse / validate incoming data at an API boundary with a tool like zod, or you do not, and just trust that the data matches the exact shape you expect, opening yourself up to completely unexpected errors / behaviors if it does not. The latter is probably a decent option if you ful…

Yes, I agree. Some sort of check has to happen somewhere to validate the incoming payload. If you’re looking for type safety, it makes sense to use Zod for this. To me it is bending the original tool (JS, async driven, weak typing) to fit a purpose it was not made for (hard typing, synchronous) in detriment of what it is that makes the tool good in the first place (IO performance).

This problem is not unique to JavaScript/TypeScript. You'll have this problem anytime you're working with unknown data.

Zod also works just fine async.

Re: Zod v4 Beta

#47

Post by egorfine »

simjnd wrote: post #43
move-on-by wrote: post #3

I only use Zod in a single library, so my experience with it is pretty minimal. One thing I have really enjoyed with it is the low maintenance. So, when I saw this post and read the first few paragraphs, I was filled with dread for having to do yet another major dependency update. Reading of all the improvements- surly the ‘breaking changes’ list must be massive. Having read the full article, it seems like the breaki…

Even if the breaking changes were massive, you could keep the dependency pinned at the version you're using and not upgrade if the new features aren't useful/compelling

That's not a feasible approach. You will have to upgrade at a certain point and the later - the more painful it would be.

Re: Zod v4 Beta

#48

Post by egorfine »

move-on-by wrote: post #3

I only use Zod in a single library, so my experience with it is pretty minimal. One thing I have really enjoyed with it is the low maintenance. So, when I saw this post and read the first few paragraphs, I was filled with dread for having to do yet another major dependency update. Reading of all the improvements- surly the ‘breaking changes’ list must be massive. Having read the full article, it seems like the breaki…

> I was filled with dread for having to do yet another major dependency update.

I am dreading. I have recently upgraded a few large breaking dependencies and at this point I'm dead inside. I'd rather remove zod and validation from the project than have another architectural shakedown of a minor piece of my project (validation).

> breaking changes have been kept within reason

There is always a reason why everything must be rewritten and broken[1].

[1] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

Post reply on HN