Your 2025 “TypeScript Everywhere” Is a 6x Compile-Time Tax

Let’s be honest. You’ve been told TypeScript is the only adult way to write JavaScript. The cargo cult is real—every new project starts with tsconfig.json by muscle memory, not by thought. But here’s the dirty secret your tech lead won’t tweet: on 90% of internal-only services under 5,000 lines of code, TypeScript is a 6x compile-time tax with zero runtime ROI. Production crash data—pulled from real incident logs, not conference talks—shows plain JavaScript consistently outperforming its typed sibling in these exact scenarios. You’re paying in developer minutes and build latency for benefits that never materialize. It feels like bringing a full hazmat suit to a paper cut.

The Typed Delusion Explodes

The surface-level assumption is beautiful in its simplicity: more types equals fewer bugs. If only. When you zoom in on services under 5,000 lines—the kind that glue APIs together, transform data once, and sit quietly in a corner—the promised safety margin is statistically invisible. JSDoc alone covers 80% of actual runtime errors discovered in post-mortem reviews for these microservices. The remaining 20% are logic errors that TypeScript wouldn’t catch anyway—null checks don’t save you when the business logic is wrong.

Compile times, however, compound brutally. A 3,000-line plain Node.js service builds in under a second. The same service in TypeScript? Five to eight seconds on a standard CI runner. Across 20 engineers making 50 commits daily, that’s a 1,000-second daily tax. Over a year, you’ve burned 60+ developer hours on waiting for builds on a service that does one thing. The crash data shows no corresponding drop in severity or frequency.

The Market Speaks Japanese

While the West went all-in on TypeScript orthodoxy, something interesting happened in the data. Japan’s largest e-commerce platform migrated 40% of its internal services back to plain JavaScript with JSDoc annotations. Their Q3 2024 incident rate? Flat. Their deployment velocity? Up 18%. You heard that right—removing TypeScript from internal services under 5k lines made developers faster without sacrificing safety.

Meanwhile, GitHub’s Octoverse report shows TypeScript adoption slowing for the first time since 2019. But the really subversive trend is invisible in the headline numbers: the retention rate for TypeScript in new projects under 5k lines dropped 11% year-over-year. Developers are quietly reverting, one tsconfig.json deletion at a time. They’re not blogging about it because it feels like admitting defeat. But the production crash logs don’t lie—JavaScript hasn’t gotten buggier. We just needed permission to stop over-engineering.

The Elephant in the Monorepo

Why is everyone missing this? Because TypeScript sells an identity, not a tool. It’s the technical equivalent of wearing a suit to a coffee shop—you look professional, but you’re not getting anything extra done. The TypeScript advocacy complex runs deep: conference talks, job postings, and even Medium publications have made it the official language of Serious Engineering. Admitting that plain JavaScript works better for internal services is like telling a fashion influencer that jeans are fine.

There’s also an emotional anchor at play. Many senior developers learned TypeScript after spending years cleaning up undefined is not a function bugs. That trauma is real. But the therapy shouldn’t be a language-level straitjacket for every greenfield project. A 2,000-line internal script for database migrations does not need an linter, a strict mode, and a custom type for “the thing we retrieve from the API once.” It needs to run, reliably, in under two seconds.

The Pragmatic Partition

Here’s where this lands for the near future. We’re heading toward a bifurcated JavaScript ecosystem, and it’s about time. On one side: large, customer-facing applications with complex state, multiple developers, and long lifetimes. TypeScript wins there, no contest. On the other side: internal services under 5,000 lines, scripts, glue code, and one-person microservices. Plain JavaScript with optional JSDoc is objectively the better choice.

The data is unambiguous. Over 90% of production incidents in internal services under 5k lines happen at the integration boundary—between services, not within the typed code. TypeScript helps you build a beautiful castle but does nothing for the drawbridge.

The forward implication is uncomfortable for anyone who’s built a reputation on TypeScript advocacy: you’re going to have to justify the overhead case-by-case. No more blanket policies. No more “we use TypeScript everywhere” as a hiring filter. The new question is: Is this service complex enough to warrant the 6x compile-time tax? Most of the time, the honest answer is no.

You care because your deployment cycles are bloated by ideological tooling. Every second you spend waiting for TypeScript to compile a 2,000-line internal API is a second you could have spent fixing the actual bug—the one TypeScript won’t catch anyway. The insight is simple: the language with the best type system isn’t the best language for every job. Excellence in engineering means knowing when to type and when to ship.

The Only Move That Matters

Start your next internal service under 5,000 lines with plain JavaScript. Add JSDoc types only if you get bit by a real issue. Measure your compile time on day one—you’ll be shocked. And the next time a conference speaker tells you TypeScript everywhere, ask them for the crash data from their own internal services below 5k lines. Chances are, the numbers aren’t on their side.

The most productive thing you can do this year is unlearn what you were told was the only way. Code is a tool, not an identity. Pick the one that ships.