🙅 Why Hating TypeScript in 2024 Doesn’t Make Sense

I’ve been seeing this trend lately: more and more developers bashing TypeScript. The gripes range from it being “too complex” to “slowing down development.”

While not all concerns are unfounded, hating on TypeScript in 2024 just doesn’t add up.

Let’s break it down. 🔍

TypeScript Isn’t Your Enemy, It’s Your Safety Net

I get it—JavaScript is flexible, dynamic, and lets you ship code fast. But that same flexibility is also what leads to bugs that are hard to catch until it’s too late. TypeScript’s strictness isn’t there to slow you down; it’s there to save you from spending hours debugging issues that could have been caught early.

Here’s an example:

In theory, id can be a number, a UUID, a random string, or a structured string. But depending on what type it is, you might get an error if you try to increment it or pass it to an API that expects it to have a specific structure and type.

And you can figure out what type it is by looking at how it’s used. But you know what makes this a non-issue?

When you add TypeScript to your project, you’re adding a layer of security. It’s like putting on a seatbelt. Sure, you can drive without it, but why risk it when a simple precaution could save you from a crash? 🚗💥 In a time where software quality is more critical than ever, TypeScript’s type-checking is a safeguard that just makes sense.

It’s Not as Complicated as You Think

Another complaint I hear often is that TypeScript is “too complicated.” But let’s be real—JavaScript can be a mess. Function signatures that accept any input, objects that morph shape, and code that’s one typo away from breaking in production. TypeScript isn’t adding complexity; it’s formalizing or standardizing it.

Think about it this way:

You’re working on the frontend side of a feature, and someone else might have some work overlapping with you. There’s also going to be backend APIs you need to incorporate, but those aren’t ready yet. You’ve been asked to begin the UI work anyway.

How do you ensure that the code you write right now is consistent with the data you’ll get from the APIs? And that if something does change on the APIs, there’s a source of truth that all parties need to adhere to?

That’s right.
By defining types.

With types defined before implementation begins, there should be no confusion about what data contracts are shared between the UI and APIs, and if something indeed is different, then all that needs to be done is to go and stick to the contracts defined earlier.

If you can learn React, wrangle with Webpack, or deal with async/await, then you can learn TypeScript. And here’s the kicker—it’s a skill that pays dividends. The learning curve is worth it because it forces you to think more critically about your code. Instead of hacking together a quick fix, you’re thinking about architecture, types, and long-term maintainability. 🛠️

Faster Development, Not Slower

There’s this myth that TypeScript slows down development. But in reality, the opposite is often true. By catching errors during compile time instead of at runtime, TypeScript helps you move faster in the long run. You’re not spending your days in the browser console, chasing down undefined variables or weird type coercions. 🚀

TypeScript’s tooling is also top-notch.
Features like autocompletion, refactoring tools, and inline documentation make the development experience smoother. You’re not just writing code—you’re navigating a well-lit, well-marked road instead of stumbling around in the dark. 🌟

Here’s a personal anecdote.
Before I fully embraced TypeScript, I often found myself in the weeds of codebase archaeology. I’d encounter a function and have no idea what arguments it was supposed to take. Was it a string? An object? What params were needed in this object? Which ones were optional? Was something that was made to look optional actually required somewhere in the callstack?

Because devs aren’t perfect, poor variable names, inconsistent naming conventions, and coding preferences get in the way all the time…

So, I’d do the dance: scrolling back to the function’s declaration, digging through implementations, trying to piece together what was supposed to go where. And if autocomplete was supposed to save me? Forget it. It was useless. The code editor was just as clueless as I was. 😅

Sure, you could argue that JSDoc comments might help. But if you’re going through all that effort to manually document types and function signatures, then why are you doing that to yourself? You’re basically doing TypeScript’s job, but without any of the actual benefits. TypeScript eliminates all that guesswork, letting you code with confidence and speed.

TypeScript Is the Future (And the Present)

TypeScript is on its 5th version. It’s basically at 100k stars on GitHub. It has 55 Million+ downloads PER WEEK on NPM. More and more major projects and companies are adopting it. There’s a reason for that: TypeScript brings stability, scalability, and confidence to codebases. It’s not just about today’s project, but about building something that can grow and evolve without collapsing under its own weight. It’s about not having to write documentation and tests separately all the time (it doesn’t entirely replace them, of course).

So, let’s cut through the noise. The hate TypeScript gets in 2024 is largely misplaced. Sure, it’s not perfect — no tool is. But the benefits far outweigh the drawbacks. It’s time to stop viewing TypeScript as an obstacle and start seeing it as the essential tool it is.

Embrace it, learn it, and you’ll find yourself writing better code, faster. 💪

TypeScript Isn’t Perfect, but don’t let perfect be the enemy of good!

Of course, TypeScript isn’t without its flaws. One legitimate gripe is the overhead of setting it up in a project that wasn’t built with it in mind. Converting a legacy codebase to TypeScript can be a time-consuming process, and it’s not always feasible for teams that are under tight deadlines. ⏳

Additionally, sometimes TypeScript’s strict type system can feel like it’s fighting you rather than helping you, especially when you’re dealing with complex types or third-party libraries that haven’t been properly typed.

TypeScript is only as good as the dev configuring it.
I’ve worked on multiple TS projects, some of which had relatively lax configurations that would allow people to use any types or avoid strict or null checks. You mix untyped or loosely typed code into a typed codebase, and the situation could end up being bad enough.

Where do we go from here?

That said, these are short-term pains for long-term gains. Yes, it might slow you down initially, but the stability and maintainability you gain more than make up for it.

And these issues used to be a lot more severe a few years ago, but it’s arguably a lot better now.

In my opinion, put in the effort to learn TS. TS enables you to partially introduce it to an existing codebase—try that. Or perhaps create smaller pet projects that leverage TypeScript.

Plus, TS devs make a bit more money than JS devs based on the most recent StackOverflow survey.

And speaking of better code…

If you’re curious about how TypeScript can level up a real-world project:

⚡️ Check out the Middleware repo ⚡️

It’s a great example of TypeScript in action, and who knows—you might just pick up a few ideas for your own projects! 🚀

Even better, tell us how our code IS NOT the best!
If you have some solid suggestions, I’ll amend the post to include them as examples!

Please follow and like us: