The TypeScript Emperor Has No Clothes

It's not a secret that I am not a fan of TypeScript. Back when I started my career as a developer, I kinda liked it when I first came across it. It felt familiar and reminded me of Java when I entered the strange and weird world of JavaScript.

Long story short: I fell in love with that strange and weird world of JavaScript and I've spent countless hours trying to master it without TypeScript. And sometime in this era, I started to second-guess the actual need of TypeScript. What problem does it actually solve?

I came to the decision not to include TypeScript in my stack since I had the privilege to decide on my own which stack I wanted to work with. And as my experience and knowledge grew, I came up with some really good arguments for not using TypeScript - or not needing TypeScript.

But... there is a but. Now and then I find myself doubting my own arguments. Are they still correct? Maybe TypeScript has evolved into this really super great thing everybody is so goddamn hyped about? When this happens, I need to go through my thoughts and arguments to check if maybe I am wrong. I mean, there are soooooo many developers loving and praising TypeScript. Who am I that thinks the opposite of almost everyone else?

The Real Question

It's important to understand that the question here is not whether TypeScript is bad or not.

The question is: Do you need TypeScript to write type-safe JavaScript in large-scale production projects?

The Over-Sold Promise

TypeScript's main value proposition is catching type-related bugs at compile time and improving developer experience through better IDE support. But here's the reality: if you're already an expert JavaScript developer who writes pretty clean, well-tested code, TypeScript's benefits become much more marginal.

The "TypeScript prevents bugs" argument often gets oversold in my opinion. Most of the bugs TypeScript catches are things like typos in property names or passing the wrong number of arguments - issues that good testing and code review already can catch. The really nasty bugs in production usually aren't type errors; they're logic errors, race conditions, incorrect business logic, or external system failures.

The Dirty Secret

The dirty secret is that most "type errors" that TypeScript catches are symptoms of other problems: poor code organization, lack of clear interfaces between modules, not understanding your data, or rushing through implementation.

When you teach people to think clearly about what their code is doing, those problems largely disappear.

The type safety argument falls apart when you realize that:

• Runtime data doesn't care about your TypeScript types

• Most bugs happen at boundaries (API responses, user input, external services) where TypeScript can't help anyway

• Good error handling and validation matter way more than compile-time type checking

The Real Problem

The industry has this weird tendency to adopt tools that solve problems we created for ourselves. Instead of teaching our future developers to write better JavaScript and understand their data flow, we add a compilation step and pretend it fixes everything.

The honest reality is that TypeScript solves specific problems in specific contexts, but those contexts aren't universal. A well-mentored team writing clear JavaScript often has fewer real problems than a team fighting with type definitions and build tooling.

The industry has become obsessed with technical solutions to what are fundamentally human and process problems. We keep adding layers - new frameworks, new languages, new methodologies instead of addressing the core issues: unclear requirements, poor communication, unrealistic timelines, and teams that don't understand the actual business problem they're solving.

A project fails because stakeholders changed their minds halfway through, or because nobody talked to the actual users, or because the timeline was fantasy from day one. But instead of fixing those problems, we convince ourselves that the next technology stack will somehow make badly managed projects succeed. It won't.

My Real-World Experiment

So why am I confident about my arguments and statements here? Is this just me trying to be bold and brave and going against the crowd?

No, it's not. Over the last couple of years, I made an experiment, you could say. For about three years now I've been working on this big project, maybe my future (but more about that some other time), and I am the only senior developer. Each year I take on a new set of students on their LIA (workplace learning). The amount has been varying between 5-11 students at a time.

Before I go further, I need to be very clear about one thing: I taught all of those students (almost all...) JavaScript. And what I am about to tell you would not be possible if that was not the case. I know that and I would never state anything else.

Like I said, I've switched teams over the years and had varying amounts of team members, but all of them have been students, not junior developers. I taught them to write thoughtful JavaScript, and surprise - we didn't run into the chaos that TypeScript supposedly saves you from. That's because the real issues aren't technical, they're about discipline and understanding.

The Results Speak

Especially the experience with the last team of 11 LIA students proves something important: when people understand what they're building and why, and when they have good fundamentals, the technology choices matter way less than everyone thinks.

But that's harder to sell than "this new tool will solve everything." What my experience proves is that understanding the problem space deeply beats adding layers of tooling complexity. I strongly believe that the developers who focus on solid principles instead of chasing every shiny thing tend to build the most reliable systems.

Trust Your Instincts Over the Hype

Again, I am not saying TypeScript sucks. I am just saying TypeScript solves specific problems in specific contexts, but as I said before those contexts aren't universal.

Your instincts as an experienced developer matter. If you're building reliable systems and your team is productive, don't let the hype make you doubt what's working. The best tool is often the one your team understands deeply, not the one everyone else is talking about.

Here's what really keeps me up at night: we've built an industry where saying 'good fundamentals matter more than tools' sounds radical. Where teaching 11 students to write clean JavaScript without being overthrown by type error feels like an impossible achievement.

That's not a technology problem - that's a culture problem. And no amount of TypeScript is going to fix it.