All Posts
TypeScriptJavaScript
Mar 5, 20267 min read

I Quit TypeScript for 30 Days. My Honest, Unfiltered Review.

After 4 years of TypeScript evangelism, I went cold turkey for a month. Here's what I learned about what TypeScript actually protects you from — and what it doesn't.

I Quit TypeScript for 30 Days. My Honest, Unfiltered Review.

I've been writing TypeScript since 2020. I've given talks about it. I've converted three teams from JavaScript to TypeScript. I genuinely believed it was one of the most unambiguously good decisions you could make as an engineering team.

Then last November, I started a new side project in plain JavaScript, mostly out of impatience. Thirty days later, I had learned things about TypeScript that four years of using it had never taught me.

What TypeScript Actually Protects You From

Let's be precise about this, because the TypeScript community tends toward vague promises about “catching errors at compile time.” After 30 days without it, I could see the boundary clearly.

TypeScript is excellent at catching: incorrect property access on known types, wrong argument types on function calls, missing required fields when constructing objects, and refactoring mistakes when you rename a property.

In my 30-day project, I made exactly three mistakes that TypeScript would have caught immediately. All three were caught within minutes by tests or by the browser. The feedback loop was slightly slower, but not catastrophically so.

TypeScript tells you when you've called a function wrong. It cannot tell you when you've called the right function at the wrong time, with technically valid but semantically wrong data.

What TypeScript Doesn't Protect You From

This is the part that humbled me. Runtime type errors TypeScript can't catch:

API response drift. The backend changes a field from string to number, the TypeScript types aren't updated, everything still compiles, and you get a NaN in production. TypeScript never saw the actual data.

Wrong third-party type definitions. I've hit this with three major libraries in the last year. The types said a function returned string, but at runtime it returned null in edge cases. TypeScript gave me false confidence.

as any proliferation. Every codebase I've worked in through a TypeScript migration has at least 50 as any casts. Each one is a lie you told the compiler. They accumulate quietly.

The Speed Difference Was Real

I won't pretend it wasn't. Writing JavaScript for 30 days felt like removing a weighted vest. The iteration speed on the initial prototype was noticeably faster. I wasn't wrestling with generics or fighting with type inference.

But by week three, I started to feel the cost. Refactoring without types was slower. I was more hesitant to move things. Two bugs slipped through that TypeScript definitely would have caught.

My Actual Verdict

Use TypeScript. But use it with clear eyes about what it actually does. It's a communication tool as much as a safety tool — it makes your intent legible to other engineers and to future you.

But pair it with runtime validation at your system boundaries. Use Zod or Valibot to parse API responses. Don't trust type definitions for external data — validate it. TypeScript at compile time plus Zod at runtime is a dramatically different safety profile than TypeScript alone.

And stop treating as any as a shortcut. Every time you write it, you're pulling a brick out of the foundation. The building still stands — until it doesn't.

Built with Passion

© 2026 Built with ❤️ & Code by Nishal Poojary.

The Land of Spirituality and Philosophy

Bangalore · India

Thanks for making it
to the end 🙌🏻

Footer panoramic mountain landscape graphic