June 30, 2026
Type safety, but make it spicy
Parse, Don't Validate – In a Language That Doesn't Want You To
Coders love this “stop re-checking everything” idea — but the comments got messy fast
TLDR: The article says programmers should clean up and trust data at the start instead of repeatedly checking it later, which can make software safer and less chaotic. Commenters were split between “this is brilliant,” “this sounds hard in real life,” and “wait, was this written by AI?”
A new post arguing that programmers should convert messy input into trusted data once—instead of checking the same thing over and over forever—hit a nerve with the TypeScript crowd. The core pitch is surprisingly simple for non-coders: don’t keep asking “is this okay?” every few steps. Turn it into a safer, more trusted form at the start, and the rest of the program can relax. In theory, everyone loves that. In practice? The comments instantly turned into a mix of admiration, anxiety, and side-eye.
The most relatable reaction came from people basically saying, “Yes, this is smart, and no, I still don’t do it.” One commenter admitted it “feels right” but spiraled into the classic fear: if one piece of data is optional, do we now need a million tiny versions of the same user profile? Another jumped in with the dry, chaotic energy of the internet’s smartest hall monitor: “Don’t forget to freeze the objects.” Helpful? Maybe. Funny? Absolutely.
Then came the real drama: the AI-writing accusations. One reader said the article “reeks” of AI, while another proposed a full-on “slop/not-slop slider” for judging posts by how machine-made they feel. Brutal. And yet—even the skeptics admitted they learned something useful, especially about so-called “brand” types, a trick for making plain text feel safer and more meaningful in code. So the vibe was pure internet: half enlightenment, half roast session, with just enough practical advice to keep everyone reading.
Key Points
- •The article revisits Alexis King’s 2019 “Parse, don’t validate” principle and applies it to TypeScript programming.
- •It distinguishes validators that return pass/fail results from parsers that return either an error or a more precise type.
- •A TypeScript example shows that after boolean validation, fields such as `email` and `age` remain typed as plain `string` and `number`, so the type system does not retain proof of validity.
- •The article argues that functions should accept parsed domain types such as `ValidUser` rather than raw input types.
- •It identifies branded types as the common TypeScript workaround for creating effectively distinct domain-specific types despite structural typing.