The TypeScript Experience
Tags: typescript, javascript, node
Published: 2022-04-10 22:43:09

---
title: The TypeScript Experience
published: true
description: Is the TypeScript experience good enough? Could a sound type system improve it? Would that even possible to implement?
tags: typescript, javascript, nodejs
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8k4ft14dwizjer9i1en3.png
---
A few days ago I read a [thread](https://twitter.com/jsjoeio/status/1511759156512006148) on Twitter where the author asked "Why wouldn’t 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](https://blog.logrocket.com/is-typescript-worth-it/) implemented in TypeScript, that similarly to Flow, is based on [structural subtyping](https://twitter.com/javierwchavarri/status/1082597156727476226). This means that TypeScript’s type system [allows certain operations](https://www.typescriptlang.org/docs/handbook/type-compatibility.html#a-note-on-soundness) that can’t 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 ([Hindley–Milner Type System](https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_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 generate type errors at runtime. Moreover, together with other design choices, like making errors explicit in the type system ("Maybe", "Either", etc.), languages that use sound type-system are able to detect other families of runtime errors at compile time.

This is a topic already discussed at length but I wonder if there are some new perspectives.

# My questions

* 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](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals), as explained above or the [unsoundness is not an issue after all](https://effectivetypescript.com/2021/05/06/unsoundness/)?
* Can TypeScript [be improved](https://github.com/Microsoft/TypeScript/issues/9825) in this respect? Or, in broader terms, can a [superset of JavaScript support a sound type system](https://hegel.js.org/) without becoming [overly complicated](https://github.com/Microsoft/TypeScript/issues/9825#issuecomment-234115900)? 
* Or maybe a sound type system can [only be achieved](https://github.com/sinelaw/infernu) either by [limiting JavaScript](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.8387&rep=rep1&type=pdf) or with a different language that compiles to JavaScript?

Let me know what you think in the comment section below ❤️

---

### Appendix - Curated overview of the Twitter thread

### • Question

Looking to hear from folks who wouldn’t use TypeScript. Why wouldn’t 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" I’ve 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](https://twitter.com/softwarefloyd/status/1512630546853208070)
* 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

## 💬

I’ve spent more time fighting missing/broken type definitions in 3rd party libs than I care to admit.
For this reason, I won’t 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<string> 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 that’s coming from someone (me) who is using TS on all their projects.

## 💬

TypeScript has to sacrifice too much to stay JS compatible. JS does not give a good dev UX by modern standards and TS does not give you a step change improvement. Try Elm!

---

For more answers, check the original [Twitter thread](https://twitter.com/jsjoeio/status/1511759156512006148).


Header illustration derived from [Like emoji vector created by rawpixel.com - www.freepik.com](https://www.freepik.com/free-vector/mixed-emoji-set_4159931.htm).

---

🔴 Does any of these answers resonate with you and your experience❓

🔴 Do you think there is something that can be done to change the TypeScript experience, especially when compared with languages that use a sound type system❓

Let me know in the comments section below