7 really good reasons not to use TypeScript

Everyone loves TypeScript. It “solves” many problems JS has, it is a “superset” of JS, it will make your code error-prone and pleasant to read. There are a lot of good reasons to use TypeScript, but I am going to give you 7 really good reasons not to.

It is risky

Wow. How can it be risky, if TypeScript adds type definitions and checks them at compile time? As well as IDE integration will warn you about any type mismatches? Exactly because of that. TypeScript will only check types at compile time and only types that are available. Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript. As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.

With JS, you make no assumptions about types, and you check the concrete value of the variable to make sure it is what you expect it to be. Or, if you do not care about its type in this particular case, you do not. In TS, you rely on the compiler to do it for you, but it can only check so much. You can combine the two ways, but what is the point then? If you will spend time writing definitions and then spend time writing code to ensure these definitions are maintained during runtime, why have them in the first place?

It is messy

Another paradox: the language that was supposed to bring clarity and readability to the codebase obscures it instead. To show you what I mean, check out some of these examples I found in popular open-source libraries:

This one is from the Redux library, and all these 4 lines do is assign nextReducer to currentReducer.

Next example if from the RxJS library. I do not know about you, but if I have to fight a tool that is supposed to help me, I do not think this is a good tool.

It does not solve the problem

TypeScript is said to solve JavaScript’s problems. But it does not. Dynamic typing was never a problem in JavaScript, but many other gotchas such as NaN === NaN being false, semicolons being optional or not optional, a linebreak changing an object definition into a scope, syntactic sugar in place of OOP are indeed problems. TypeScript does nothing to solve them, but introduces yet another standard, further polarizing the JS community.

Even under the assumption that the lack of typing in JS is a problem, TS does not solve it. Do you know what does? Java, C, C# and other compiled languages. They can safely guarantee strong typing at compile time and runtime. Interpreted languages are just not capable of it.

It is not a superset, it is a subset

TypeScript is something that compiles into JavaScript, it cannot be a superset by definition. It limits what you can do with JavaScript and obscures its strong sides while providing a fake peace of mind. If you really want to be a great developer, do not settle for a comforting lie and try to understand the true power of JavaScript and its flexibility.

It is open-source, but nothing more

Many reasons for using TypeScript state that it is open-source. That is true, TS compiler is distributed under MIT license. But it is still controlled by Microsoft, a giant monopolistic corporation, and its open-source advancements are nothing but a marketing move. Do not confuse open-source with democracy: Microsoft is still free to do anything you want with TS, and you are just here to watch. JS, on the other hand, is governed by an international committee and will not change anything without the community’s approval.

But big companies use it…

I cannot believe that some people consider this a reason. Big companies also use legacy codebases, commit tax frauds and discriminate against women. Why all of a sudden them using TypeScript is a good example?

But it has more features…

Not anymore. True, when TS was first introduced in 2012, it had features like classes, still not available in JS. But JS had come a long way since then, and now TS is struggling to keep up. If there is anything missing in JS, there is a babel plugin to do it.

Thank you for reading, I hope you liked this article! For more info about advanced concepts in JavaScript check out my other posts:

Get new content delivered to your mailbox:


  1. rob | may 25, 2020

    Interesting article. Thanks for sharing!

  2. johnny | may 31, 2020

    Really good article. I think Typescript had a reason to exist when it was created 2012. Nowadays, it is true that it offers fewer advantages, we deserve a better alternative but… it’s a religion in hype.

  3. xenock | june 24, 2020

    Thanks to god! There are some people thinking as me.
    I am agree with all of your arguments, and think as Johnny too: “It’s a religion like”

  4. matt | july 3, 2020

    This seems like a pretty biased article to me.

    Risky? It’s meant to be a help you catch some things earlier, it should not replace your tests which should catch issues whether using JS or TS

    Messy? It can be used in a way that is pretty visually verbose e.g. in a complex library. This is generally to give user of the library and the IDE a more discoverable and informative experience when using the library. Actually using it in your application, it is often very clean syntactically and at a glance describes what something is.

    Doesn’t solve the problem? Humans are the ones writing JS. It is very easy during development of an application that you miss something innocuous which causes a runtime error. Risk of this is dramatically increased if refactoring a large project with similar named code structures. So it goes a long way to reducing human mistakes from dynamic typing

    It’s not a superset, it’s a subset? Same point as above, humans are the subject here, not Typescript itself. It allows humans to state and enforce a super set of functionality like abstract classes and methods, JS adds and is planning to add some of this into JS which is great and ideal. But in terms of the code written and delivered, it offers a superset of ways to write code that does exactly what you intend and can’t be written in the wrong way (by another developer)

    But big companies use it? They often have high standards, have the goal of making money and want to use the best technology available. It surely lends some credibility to TS that hugely successful tech companies see the advantages.

    If you are responsible for a large project with multiple developers where you want to continuously want to refactor it by applying your latest knowledge to have the best platform it can be – you can easily see the value it offers.

    Team members can share explicit definitions of their code with others. This is great for other develops as the code becomes much more discoverable and you have reduced their ability to cause unintended problems using your code via strict type annotation.

    You can also refactor with confidence, personally I have done Ctrl+F replaces when I have accidentally changed the name of a variable with a similar but different name. Typescript flags this in the IDE, giving you much more confidence and increasing the quality of your code.

    Why might not want to use it:
    – Rapid prototyping
    – Easier debugging via straight JS
    – Straight JS may have better performance since you explicitly structure your code compared to whatever Typescript generates.

    There are reasons to use it and not to use it but it’s a balance. All or nothing one way or the other is self defeating

    • michael krasnov | july 6, 2020

      Yes, I agree it is biased (after all, I post my personal view on the matters on this blog). And I am not saying you cannot make TypeScript work. What I mean is that this is not a solution for the inherent JS problems, and it is possible to create a sound codebase without depending on TypeScript. As for the big companies, do they really produce quality software? I mean, TypeScript is from the same company that wrote Windows, and while Windows is very robust and gets work done, I would never go as far as suggest it works as good and as predictable as Linux/macOS

  5. There’s so many more reasons that that.

    I can’t think of any reason TO use TypeScript. It’s demonstrates a fundamental misunderstanding of programming to purposefully “convert” a loosely typed language into a strongly typed ones. As if the open community of computer scientists that are responsible for the evolution of JavaScript just keep just “forgetting” to add types to their loosely typed, dynamic language.

    What is the practical difference between a double and a float type in C? The answer to that question is the original reason for using types, and it’s something that JavaScript developers, thankfully, do not need to worry about.

    Not to mention that it is not compiled, it’s transpiled. It’s converting one language into another one. What you end up with is still JavaScript – it’s just JavaScript written by an algorithm with a whole bunch of polyfill and/or other unnecessary bloat inserted in order to accommodate the programmer (as opposed to accommodate the solution to the problem). This is the wrong tool for any job and especially any job that is performance sensitive.

    Good programmers should know more than one language and be comfortable with multiple programming paradigms. If you need TypeScript in order to feel comfortable with your code base, that problem exists between the chair and the keyboard.

    The ultimate sophistication is simplicity. TypeScript is a huge swing and miss from the corporation that also bought the web Internet Explorer and Silverlight. Why would anyone want to insert a layer of complexity into their build process in order to program in a different language than the one natively interpreted by the client? It seems so ridiculous I can’t believe it’s so popular. I would pass, but unfortunately it seems it’s so hot right now with hipster front-end developers, I’ve got no choice but to use it.

  6. The thesis of this post seems to be: “Typescript doesn’t solve every problem, so don’t use it.” I mean, no technology solves _every_ problem, but Typescript prevents a whole heck of a lot of bugs in my experience. And thus should be used in most JS circumstance while — as with any technology — understanding its limitations. It’s one more tool in the quality arsenal. Alongside unit testing and, of course, thoughtful software design.

    • michael krasnov | august 31, 2020

      What I meant to say is “typescript does not solve JS problems but creates new ones, so don’t use it”. Carefully designed JS code prevents a lot of bugs in my experience, and TS will just mitigate the symptoms of a rotten codebase for a while, but will not make the problems go away, as it is no substitute for clean code.

  7. george j beier | september 10, 2020

    Sure wish they’d just add types to js itself. “let int x = 3” or something like that. Would sure solve a lot of problems.

  8. This is a brave article; very courageous to put your views out there like this, knowing the combative responses and disagreements you’re inevitably going to have to face. I appreciated the article. It was a fun read and had some good points. And I must agree, I can’t see even a halfway-decent reason to write in TypeScript. I’ve searched high and low, and that’s even one of the reasons I found your article to begin with: searching for a reason to use it. But all I’ve found is very clearly dumb opinions and faulty appraisals.

    There’s this weird thing I see all the time in the opinions of TypeScript users, which is that they feel it’s a great, clear improvement over ECMAScript, but then they say stuff that proves, in detail, that they don’t understand ES or loosely-typed functional programming very well. They make comments and describe concepts that just don’t make any sense to those who have a sound education in ES. They talk about it like it needs more data types, like an old strongly-typed language from the 1970s, as though there isn’t a great reason NOT to have more data types.

    So as far as I understand it, TypeScript solves a problem that ES writers should not have. And for those who DO have that problem, the real problem seems to be that they have the wrong idea about how to write ES. They see TypeScript as a solution because they write in a style where it becomes a solution to the problems they are having, but if they used the language as it should ideally be used, they wouldn’t even have personal experience with those problems to begin with.

    It’s really hard to explain this stuff to people who like TypeScript. It’s like explaining to Java or C# writers that they don’t need to use classes in ES, and that by using classes in ES, they’re just wasting their time enormously. People who have that mentality just think it’s what has to be done. And people who love strong typing seem to be the same way. It’s very difficult to convince them that they’re only hurting themselves by trying to enforce additional data types in a language that was designed to be used without them.

  9. How can typescript be a superset of JS if it just breaks some aspects and essence of the of the language itself? TS is nonsense and makes lazy programmers for JS env. While it surelly gives some help for ppl using code in finding parameters and there respective ‘types’, I don’t like this. There are reasons why ECMA don’t officialize types in a dynamic typed language.

leave a comment