A few days ago I read a thread on Twitter where the author asked "Why wouldnt you use TypeScript?" to people that wouldn't use TypeScript.

Reading through the answers, the perceptions of TypeScript among people that wouldn't use it are that

• It is intimidating
• It is an overhead
• It makes it tedious to write code
• It makes it harder to read code
• It slows down development
• It doesn't protect from runtime errors

These seem not direct critiques of static typing in general, but rather a consequence of the specific unsound static type system implemented in TypeScript, that similarly to Java, C#, and Flow, is based on structural subtyping. This means that TypeScripts type system allows certain operations that cant be known at compile-time to be safe, type inference might be not correct, and it requires some level of manually-written type annotations.

In contrast, other languages like Rust, Haskell, OCaml, Elm, and F# have a sound type systems, like the HMTS (HindleyMilner Type System), that do not require type annotations, and the types are always inferred correctly. These type-systems make sure that the code will not have errors at runtime.

This is a topic already discussed at length but I wonder if there are some new perspectives about the future direction of TypeScript or new possible alternatives.

To better understand:

• Are these answers reflecting a significant reality or are they just the complaints of a small minority?
• If the unsatisfaction is relatively common, is it correlated to the TypeScript's unsoundness, as explained above or the unsoundness is not an issue after all?
• Can TypeScript be improved in this respect? Or, in broader terms, can a superset of JavaScript support a sound type system without becoming overly complicated?
• Or maybe a sound type system can only be achieved either by limiting JavaScript or with a different language that compiles to JavaScript?

Let me know what you think in the comment section below.

Curated overview of the Twitter thread

Question

Looking to hear from folks who wouldnt use TypeScript Why wouldnt you?

Answers

In my day job, I have to use Typescript. In my projects, I refuse.

• Tedious writing types which 99% of the time are completely unnecessary, but required by the TypeScript compiler
• Does not catch bugs
• Reading code becomes much harder
• Still needs runtime checks

Because the type system is unsound and it seems to be way more complex and magical than what I would want from my type system.

I spoke to a few. Found 2 types:

• Just starting and intimidated by the wave of red
• Experienced enough to avoid the common JavaScript pitfalls and did not get the aha moment from TypeScript

Because TypeScript slows down the development of greenfield projects. It's a tool that benefits for a certain scale.

Part of it was that the flexibility of JavaScript is one of its core strengths so by removing the flexibility you're removing something good.

TypeScript is very useful and I find it invaluable in my day job, but it can be overkill for very small and one-off things. For other projects, there are other strongly typed compile-to-JS languages with more attractive type systems that are sometimes suitable.

I'm not sure if the overhead of TypeScript is enough to justify type issues in JavaScript. Maybe in huge projects.

I have tried it but had lots of problems with it. Also because some of my functions return values of different types depending on the situation. In the end, I don't get enough benefit from it. Type safety is nice to have, but I think I prefer the flexibility of JavaScript.

It's hard to use a bad type system when you've used good ones in the past.

I'm using it on my current project because stability is increasingly important, I wanted an excuse to learn a new thing and not get left behind, and I've been wrong before about new tools so I figured I'd give it a shot. But overall it's cost me more time than it's saved.

• Bloat (readability perhaps being the most important aspect of code)
• Need to safeguard stuff for the runtime regardless of whatever "guarantees" Ive gotten ahead of that time
• Further from the metal
• More tooling to know and maintain

It slowdowns development time if you aren't used to it already. I've spent days working on things trying to type them while writing the code that could have been done in a single day.

From a huge supporter of TypeScript:

• Compile times can increase if not incremental builds or static type checking
• "Clever" devs abusing it
• No real guarantees, just assurances
• A lot more code to manage
• Some libraries have less than desirable type definitions

Heavy, a bit slower, and overkill for most projects. We spend a lot of time researching good libraries to avoid writing too much code by ourselves - then why use TypeScript and write all that (mostly unnecessary) code. And most importantly - doesn't catch all bugs (not even close)!

• Too much time spent pleasing the type system.
• Too many different configurations.
• I don't need to have a step before running JavaScript code on Node.js, why would I add one?
• No runtime-type checking

Ive spent more time fighting missing/broken type definitions in 3rd party libs than I care to admit.
For this reason, I wont ever choose TS again.

Cost to Benefit ratio is too high for some projects:

Benefit:

• It's good to know the type of function argument (Especially for libraries)
• Intellisense
• Knowing error before runtime

Cost:

• It's another skill to learn. TypeScript is huge
• It has flavors. I have seen Array or string[]
• TSConfig is another pain
• Types can be too complex, why can't it just be a mix of primitives
• The errors are overwhelming. I use eslint, it only warns

We wrote enough Java in our careers.

• The syntax can get verbose and unreadable
• Everything (build, test, IDE) is slower
• Not enough libraries come with types
• Sometimes spend an hour just to appease the type system

And thats coming from someone (me) who is using TS on all their projects.

For more answers, check the original Twitter thread.

Header illustration derived from Like emoji vector created by rawpixel.com - www.freepik.com.