[techpression]

I've seen TS hurt more than help in many cases, because people think types define the world, and then they get malformed JSON (or just a new structure) and their world crumbles.

Yes, it's a skill issue, but oh dear the amount of developers who have that issue.

[Timon3]

How does TS make these situations worse? Seems to me that it helps a ton with identifying and fixing these issues. Either you can get away with just replacing the assertions with type guards, or you'll have to refactor some stuff (which is also much easier with types).

At worst, TS can only really be as bad as JS, no?

[techpression]

The illusion of safety.

”Look the type says the data has this shape”, but it doesn’t. This has led to so many cases of ”no data validation” in my experience, how people solve that is usually then with zod, and now you have added a massive runtime dependency instead of local validation.

[Timon3]

You say that as if inexperienced devs would naturally drift towards doing data validation without TS, but that hasn't been my experience. Instead what I used to see were lots of unnecessary/repeated checks spread throughout most source files (and which frequently didn't catch the actually problematic cases), which I've seen much less frequently in TS projects.

Even without TS, I'd be using zod (or a similar library). I haven't had any issues with zod's bundle size, and I don't see a good reason to write custom encoders/decoders everywhere.

[adamddev1]

That sounds like people who don't understand anything about the messiness at the boundaries of the program. Just because there's a type defined, it doesn't mean that the data from the outside world will fit that type.