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:
let id;
getUserByID(id);
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?
let id: number;
function getUserByID(id: string) {...}
// and that's the most basic thing you could do
getUserByID(id); // boink, error!
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!