[8s2ngy]

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking changes outlined in the migration guide. 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. Having maintained a few frontend projects that are 4-5 years old at work, I really empathize with them.

In my experience, large React projects often depend on a multitude of libraries, and when each one rolls out substantial changes—sometimes with barely any documentation—it can quickly become overwhelming. This is honestly one of my least favorite aspects of working with JavaScript. It just feels like a constant uphill battle to keep everything in sync and functioning smoothly.

[nicksergeant]

I am 100% in agreement here. I operate a couple large Next.js apps and in the last year we've had to deal with Next.js 14 -> 15 which introduced a ton of breaking cache changes, Next.js pages -> app router, React 18 -> 19, Eslint 8 -> 9, and Tailwind 3 -> 4.

It's honestly been a nightmare, and I wish I had just built in Django instead. The Tailwind 3 -> 4 migration was probably among the most painful, which I was not expecting.

[Daishiman]

I will continue to beat the drum that using easy-to-migrate frameworks like Django that don't go around introducing major breaking changes is one of the bigger web development superpowers.

[hombre_fatal]

Django doesn't run in the browser though. All of the tech they listed can run in the browser which gives you other superpowers at the expense of having moving targets, but that's what they opted into when they decided to run code on user machines instead of in a single server environment.

[skydhash]

The main browser API is pretty stable, all things considered. It's just that people can't seem to stay put on a given design, instead trying everything under the sun.

When you have something like SDL which is at it's third version at 27 years old, I'm very doubtful about the culture of NPM/JS world. A closer example is jQuery which is also in its third version at 18 years old.

[hombre_fatal]

True, the browser API might be stable, but the best way to build stateful client applications is unstable.

It's a constantly improving and experimental domain - not just on the web but also the desktop and mobile environment.

Next.js is a good example since it (and its competitors) are a natural iteration on top of SPAs where you want the first request to the server to also inline the initial state of the SPA to remove the double-request problem.

But you pay a huge price trying to live on the edge like that, and when you run into issues, it doesn't make much sense to call that the state of web development since you could have used boring server tech or even a boring React SPA which also hasn't changed much in a decade.

[pier25]

jQuery should get more praise for this.

[pier25]

Couldn't agree more. I'm considering getting into Phoenix for this very reason.

[winstonp]

i am just simply not touching tailwind v3 -> 4. v4 is for new projects only.

[egorfine]

OPINION WARNING

Eslint 8 → 9 was not just incredibly painful with a shock wave that still propagates through the industry, but it was also totally useless

[ruined]

that's why they're taking the dual-availability approach, with a separate 'mini' edition. it's easy to perform a progressive migration without messing with the package manager.

consumers uninterested in the 'mini' edition don't have to bother with that part.

but, the benefits of the 'mini' edition are so drastic for tree-shaking that it was driving development of alternatives - zod had to either do it (and benefit), or deprecate.

[JoRyGu]

Was just looking at their release strategy. This is being handled by people that have experienced the hell that is dependency management in the JS ecosystem. Kudos to them.

[koakuma-chan]

> 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.

[cscheid]

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.

[koakuma-chan]

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.

[collingreen]

"It will solve all your problems!"

"It didn't solve my problems"

"You're the problem!"

[koakuma-chan]

> "You're the problem!"

He said users sent reports with hallucinated syntax, he wasn't even the one who used LLMs.

[elanora96]

I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. It also kept telling me to install irrelevant dependencies saying my code would not work without them. My experience was more or less shared with several other senior devs using their companies AI subscriptions. Are we all using the tools wrong? Or is there just an expected amount of having to fight with the machine to get a usable result?

[koakuma-chan]

> I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide.

I have never used Cursor, but I see more and more people who used LLMs specifically via Cursor complain. It makes me think there's an issue specifically with Cursor, e.g., they try to save on tokens and end up not including enough context in the prompt.

> I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide.

I am working on a Next.js 15 / React 19 app, and at least 95% of code is written by Gemini 2.5 Pro Preview, and I barely ever need to "fight" it really. But it's not a Cursor workflow of course. I keep a directory with LLM-readable documentation[0], use a repository serialization tool to serialize my repository into a prompt (this includes both the source code and the LLM-readable documentation), and send it to Gemini 2.5 Pro Preview. It ends up being over 100K tokens per query but works really well for me.

[0]: https://llmstxt.org/

[camgunz]

And then pick through all the LLM's mistakes.

[rvnx]

Ask another LLM to pick for you

[sensanaty]

LLMs can't even not write React when you explicitly tell them not to write React in your Vue codebase. I still, with Gemini 2.5 Pro and Claude 3.7 both, get this annoying ass interaction almost daily, despite a universe of context there that should make it obvious I don't want a React component in my Vue codebase.

[9dev]

Do you mean TSX? Because Vue supports that. Might be worth asking it to create a SFC file and no TSX explicitly in your case!

[owebmaster]

better yet: use an LLM to generate a subset of Zod that is fit for the project