by mycroft_4221 on 4/12/25, 9:03 PM with 47 comments
by move-on-by on 4/12/25, 10:19 PM
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 breaking changes have been kept within reason. One major improvement that stands out to me is the improved Recursive types support, but there is certainly any number of improvements for others to be excited about.
The thing I enjoyed most is that excitement of the Arthur really shines throughout the whole article. I’m so thankful this library exists and is being lovingly maintained by someone who is genuinely interested in it.
by Rodeoclash on 4/12/25, 10:25 PM
That said, we are slowly phasing out our React frontend for one of our apps page by page and replacing it with what we use over the rest of apps: Phoenix + Liveview. The changeset system for validations has proven itself time and time again to both be fast but also to handle many of the curly validation problems we might have. It also has barely changed since its release.
If you have a disciplined frontend team then you might be able to make it work. They have to be able to ignore the latest shiny thing that has come along, but if you don't then you'll have a team that is busy constantly upgrading to the latest shiny library rather than getting anything done.
by adriancooney on 4/12/25, 11:20 PM
by _fat_santa on 4/12/25, 10:38 PM
by petesergeant on 4/13/25, 5:19 AM
> Zod 4 introduces first-party JSON Schema conversion via z.toJSONSchema().
by gajus on 4/12/25, 11:38 PM
Zod is great in terms of API, but a no-go in terms of performance.
We ended up writing babel plugins (https://github.com/gajus/babel-plugin-zod/) and using it along with zod-accelerator, which improves performance, but breaks in various edge-cases.
by cianuro_ on 4/13/25, 3:09 AM
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.
by _heimdall on 4/13/25, 12:26 AM
I've been bit by performance issues, and even a few issues where I just couldn't infer types, with some of the more complex schemas I tried to define, especially with multiple .extend() and .omit() calls.
The zod-mini library looks particularly interesting. I don't mind the more functional approach with nested functions rather than chaining. Reminds me of ramda, that library is pretty massive but still easy to tree shake since everything is functional.
by mary-ext on 4/12/25, 10:36 PM
by cjonas on 4/12/25, 10:39 PM
by machiaweliczny on 4/13/25, 2:58 PM
by darepublic on 4/13/25, 12:38 AM
by aleksiy123 on 4/12/25, 9:45 PM
by jmull on 4/12/25, 10:42 PM
v3 didn't last four years. Can we expect much different from v4?
If you're migrating your zod 3 code, I'd migrate to something more stable and long-lived than v4 is likely to be -- unless you want to be going through it all again in a few years (and yet again a few years after that, etc).
I don't blame the maintainers (I assume they don't have a fat support and maintenance contract)
But developers need to go in with their eyes open when it comes to adopting these throw-away libraries and frameworks.