←back to thread

Zod v4 Beta

(v4.zod.dev)
175 points mycroft_4221 | 7 comments | | HN request time: 0.801s | source | bottom
1. cianuro_ ◴[] No.43669756[source]
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 about. Maybe the benefits outshine the risks in disciplined teams that understand both the tool and the runtime. However I can’t help but think about the less disciplined teams abusing Zod and then wondering why things are slow.

replies(2): >>43670282 #>>43672042 #
2. sureIy ◴[] No.43670282[source]
> I completely understand TypeScript, Zod not so much

Different tools. I only use TS but once you add external data to the mix you cannot escape `any` and `unknown` — so what you do is use `as`. Congrats, your types are now useless.

Zod would close that gap as it enforces types on external resources (e.g. `fetch` or `readFile`)

replies(1): >>43671534 #
3. gavinray ◴[] No.43671534[source]
That's not necessarily true.

You can write type assertion functions that validate the input is a given shape.

In theory, you'd use these type assertion methods at any API boundaries a single time for external inputs/outputs in a "Parse, Don't Validate" approach to cover your bases.

replies(1): >>43671678 #
4. mijamo ◴[] No.43671678{3}[source]
Soooo exactly what Zod is doing?
5. __jonas ◴[] No.43672042[source]
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?

replies(1): >>43673856 #
6. cianuro_ ◴[] No.43673856[source]
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).

replies(1): >>43675606 #
7. shepherdjerred ◴[] No.43675606{3}[source]
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.