Zod 4

Original Article ↗ Hacker News Discussion ↗

Project understanding & docs / site UX

  • Several commenters had never heard of Zod and found the release page confusing, wishing for a one-paragraph “what this is” and a clear link to the main docs.
  • Some praised the docs UX and section-highlighting animation; others noted the site fails on Safari due to unsupported regex features.

Comparisons & alternatives

  • Zod was compared to ArkType, Valibot, TypeBox, AJV/JSON Schema, Effect Schema, Typia, and Spartan Schema.
  • ArkType is praised for speed and TS-like syntax; some find it “a nightmare to use” while others prefer its ergonomics and Standard Schema support.
  • TypeBox and AJV/JSON Schema are seen as better for cross-language validation, but Zod is favored for transforms, refinements, and handling non-JSON values (Dates, classes).
  • GraphQL is mentioned as a different but overlapping ecosystem that can provide strongly typed responses without separate schema duplication.

Schema duplication & single source of truth

  • Many lament duplicating shape definitions across TS types, validators, OpenAPI/Swagger, ORMs, and clients.
  • Some use Zod as the central schema source, generating or deriving types, docs, and validators for different layers, or converting to/from JSON Schema/OpenAPI.
  • Others argue true language-agnostic sources like OpenAPI or JSON Schema are better “truths,” especially when backends are not TypeScript.

TypeScript, runtime validation & Standard Schema

  • Strong frustration that TypeScript doesn’t expose its type model at runtime; hence many parallel schema systems (Zod, JSON Schema, etc.).
  • Some want TS itself to handle runtime checking; others insist runtime validation for external data should remain opt-in libraries.
  • Standard Schema is cited as a possible unifying spec that multiple validation libraries, including ArkType and Effect Schema, are aligning with.

Zod 4 features & design

  • Noted improvements: faster type-checking, better recursive type inference, more precise .optional() semantics, transformations/refinements, and built-in JSON Schema export.
  • Zod 4 introduces zod/v4 plus a tiny zod/v4-mini core; library authors are advised to depend on a shared core layer to avoid duplicate bundles.

Versioning & migration strategy

  • Zod 4 ships as [email protected] with /v3 and /v4 subpaths to avoid a “version avalanche” in dependent libraries that publicly expose Zod types.
  • Supporters see this as a thoughtful, Go-like approach enabling incremental migration and simultaneous v3/v4 support.
  • Critics find it semver-confusing, worry about IDEs auto-importing the wrong path, and argue for a separate zod4 package or classic major bump with backported fixes.

Performance, bundle size & relevance

  • ArkType benchmarks show big speed advantages over Zod; some choose ArkType for high-throughput API validation and client performance.
  • Others argue Zod is “fast enough” for typical form validation and that benchmarked bundle sizes from sites like Bundlephobia are misleading without tree-shaking context.
  • The v4-mini split is applauded by some and questioned by others who fear both variants might end up bundled.

Modeling complex API shapes

  • A long subthread digs into modeling partially-populated entities (e.g., Users with different field subsets per endpoint) using discriminated unions, optional fields, and composition.
  • GraphQL is highlighted as solving this neatly by typing responses directly from query field selections.
  • Suggestions include separate schemas per endpoint, duck-typed narrowing based on property presence, or changing API responses to separate nested resources.

Ecosystem churn, migrations & LLMs

  • Several commenters express fatigue with constant breaking changes across JS/TS tools (React, Next.js, Tailwind, ESLint, etc.), and see Zod 4’s migration demands as yet another burden.
  • Some propose using LLMs to automate migrations; others report poor experiences with tool-assisted upgrades and warn about hallucinated syntax.
  • The Zod maintainer and some users emphasize that the dual-version approach is designed precisely to minimize this pain.

Use cases beyond SPAs & broader reflections

  • One thread argues that in non-SPA, server-rendered apps (Laravel, Rails, Livewire, htmx, etc.), framework-provided validation makes tools like Zod unnecessary.
  • Multiple replies counter that Zod is widely used on backends and in data pipelines, especially when there’s no heavy framework or when schemas cross team boundaries.
  • A few see Zod (and similar tools) as essential for safe schema evolution across teams and as protection against subtle data-shape errors.