8 myths of TypeScript
I'm often asked why I prefer JavaScript to TypeScript, and even why I openly criticise TS. One of my such elaborations has been censured by some senior backend architect, but when I asked for reasons, there weren't any. The only keywords flying around were: "Microsoft" and "popular".
So we have a self-fulfilling prophecy, where young devs learn TS because it's "The" language of WebDev, with the highest number of jobs in the market, and companies hire TS devs because they're the easiest to find.
And hence the concept for this article was born.
Initially, the plan was simple: go to the TS website and debunk their claims. But as I soon discovered: there weren't any! The TS website doesn't even mention a single benefit for using TS over the native platform (and I cannot blame them).
No matter, there must be plenty of other sources where people discovered how great the TS was and praised it all over their blogs, right?
No… not really.
It was extremely difficult to find even 5 decent blog posts that mention any advantages of using TypeScript. But eventually, I managed to find a couple, and fused them into the following list.
Wrong reasons to use TypeScript
1. It has types!
Yes, this one is obvious. It is in the name: TypeScript. Whether it is an actual reason to use it, is another matter. Probably depends on personal preferences more than anything else. If someone started their dev journey in the java world, and then was forcefully shoved into the front-end, I can imagine that not having types may be quite overwhelming. However, if someone started their web development journey from web development technologies, like HTML, CSS, javascript, than types are restricting how we write our code, adding mess, noise, unnecessary bloat, and for no good reason.
2. It is a Superset of JavaScript
This is not entirely true. The syntax is similar enough, so that JS syntax is valid TS syntax.
The confusion comes because that part is often omitted, and people are under the impression that their JS code will automatically be accepted by the TS compiler. It won't.
The simplest example is this:
const foo = {};
foo.bar = 42;
This throws a TS compiler error because it infers a type for the foo constant from the assignment, and that type is an object without any properties.
So if JS code is not (always) valid TS, and TS code is obviously not valid JS, then there's no subset/superset relation here. The correct conclusion is that TS is a separate language, that:
- is similar in nature to JS,
- it can be compiled to JS,
- it tries to follow JS conventions,
- but it also has many other things that are drastically different from JS.
3. It’s popular
It is popular, but it also isn’t. HTML is more popular, SQL is more popular.
A hammer is also popular, but it's not the best tool to fix a watch. Many people have dogs. Should every person in the world have a dog?
Popularity is not the reason to use something. On the contrary.
4. It’s Open Source and Backed by Microsoft
Yes, it's OS. So is JavaScript. However, JS is not backed by Microsoft, but by the whole world’s community of devs. And I would argue that this is a good thing.
Microsoft is a corporation with primarily financial goals, and I would prefer not to have my development led by their agenda.
It is evident, however, that corporate dollars back TypeScript and drive its popularity to absurd levels.
5. Big companies use it
Big companies use it because it's backed up by Microsoft, but this reason is as false as all the others on this list. Angular was once backed up by Google, and its lifespan was very short. Corporations invested millions writing their apps in Angular, and when v2 (AngularJS) came out completely different, everyone was rewriting or was left behind.
So this means nothing.
There’s no deal with Microsoft, where they agree to support it forever, and fix all bugs for everyone. If they get tired of maintaining it, they may move to something else just like that.
6. It has compile-time safety
This one is actually dangerous, as depending on the use case the safety might be misleading. Yes, if verifies at compile time, that variables can only contain values that we define, but at runtime variables may receive data from external sources (user input, REST services), which may not always come in the expected format, and then TS compiler is happy, we're happy, but the app still "no working".
In pure JS, on the other hand, you don't rely on fake types, so you always manually validate the data format coming from external services, and thusly, handle any errors better, than with a throw up in the console.
7. It’s easier to refactor
No, it isn't. From my experience with big and small codebases, when TS is involved, it's usually because architects prefer OO programming. So classes are used everywhere, and these are extremely hard to refactor.
And they grow, and grow and no-one dares to remove anything, only add more stuff, and we end up with files of 1k+ LOC, that are absolutely non-refactorable.
In the JavaScript world, modules and pure functions are more common, which are much easier to refactor and move around.
8. It has better performance
Another one that doesn't make sense. TypeScript compiles to JavaScript, so there's absolutely no way that it performs better.
Maybe the author of this claim read somewhere that once JavaScript engines would pre-optimise the code at runtime, and one of such optimisation was determining the types of variables for memory allocation, and changing data types was more costly. Even so – this is irrelevant, as TS compiles to JS before this happens.
Moreover, when you take a good JS dev and a good TS dev and give them the same problem to solve, my bet is that JS code will be faster by nature, as TS code is compiled by some algorithm, rather than snugly tailored to the specific solution.
Conclusion
TypeScript is not the first attempt by a large corporation full of java developers to put a harness on JavaScript development. Google tried that before with GWT and there were many other failed efforts, like CoffeScript or ClojureScript, to come up with a "better" language that could be compiled to JavaScript. But all of them remained in their niches because ultimately, they don't measure up.
I have a considerable hope that people will eventually realise that TS is nothing more than an unnecessary noise in their news feeds and their codebases that not only slows down the development but makes everything unnecessarily complex and verbose. Without a single real benefit. There are some who already have, like Deno, Svelte or Turbo 8. True, that their authors argue that these are specific use-cases, and it shouldn’t reflect on how good/bad TS is in general. But the fact remains, that they previously jumped ships just to realise that being popular and hyped, is not the same as being useful.
Epilogue
Ultimately, this boils down to a personal preference: whether you prefer to take the train, which only goes on tracks, and may be faster at times, but every obstacle requires a full stop, or you're roaming free on horseback through steppes and rivers, taking the shortest and most beautiful route to your destination. Yes, you need to know how to ride a horse, but the experience is exhilarating, in comparison.
And now I will leave you with a quote on TS, that nicely summarises its usefulness:
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.
Source: 7 really good reasons not to use TypeScript
Member discussion