Typescipt tax

[janhesters]

Hi Kent,

Are you aware of the "TypeScript Tax"? And that it can have a low or even negate ROI of time? If yes, what is your opinion on these issues?

I'm asking because at my startup we experienced that phenomenon in a major way. We switched back to JavaScript (for now).

Best regards, Jan

[hedgerh]

What tax did you experience? I was a bit of a Typescript/Flow skeptic, but I will never again do a project in plain Javascript. Maybe I can help you with the pain points that you were experiencing.

[janhesters]

@hedgerh If you read the link I provided it will be explained in detail.

For my startup what it came down two where two major TypeScript flaws:

1. TypeScript caused cost more time than it spares. The majority of bugs that it does catch are found fast (e.g. if you access a property of an object that can be undefined). So time savings are small. At the same time when you are new to TypeScript you spend hours learning it. And even after about 3 - 6 months when you became familiar with TypeScript you have to write about 25% more code and edge cases can still cost you hours of googling.
2. A lot of awesome functional programming techniques can't be typed (as of now). Check out Ramda's types to see how terrible they are (even though vanilla Ramda is great). This resulted in having to any stuff or go through the search process described in 1.

There are more points (like static types remove flexibility, on-boarding time, all tight-coupling problems that come with classes / interfaces, IDE experience etc.), but these are the two huge that massively tip the scale into vanilla JS's favor.

Haven't you encountered these observations?

[jLouzado]

Interfacing with Ramda is definitely a huge issue, but ideally those would be isolated and tested heavily and for the rest of the codebase that's written normally it's hugely useful to have the typings that TypeScript provides. :)