Ask HN: Is TypeScript worth it?

I am singling out TS because although most good libraries have documentation for all of their methods, along with examples, many useful and popular libraries do not include full documentation of their types. Some hardly any at all.

Usage examples are some of the most useful piece of documentation you can have in a library, but many authors choose to show their examples in JS, in order not to be too opinionated. It is the fact that TS is not actually part of the language, and simply an add on, that I believe is the cause of many of these issues.

> What benefits does it bring (ignoring the biggest one of them all)?

I do believe it brings benefits and agree with what you have written, of course my view is that those benefits just aren't worth the effort. In my experience some of the best codebases I interacted with were neatly written and well documented JavaScript codebases - no TypeScript, whereas many of the TypeScript codebases have been very hard to understand and work with. This is by no means due to TypeScript, however it doesn't make me think that it helps in terms of making anything that much better.

I can't even remember many times TypeScript has actually prevented a bug, it's been more useful for documentation. But then I would prefer JSDoc which isn't so difficult to maintain and can still provide autocompletion for you.

I will be using vanilla Javascript in my own projects for the foreseeable future.

I have not found, even in really large projects with thousands of files, that its been an impediment to anything.

My general disposition is the whole "anti build tools" moment is a bit overblown in practice, and I'm always searching for valid counter evidence of persistent issues that can't be easily overcome.

Can you think of cases where it's actually prevented a bug where that piece of code is unit tested? I have been actively monitoring for this to happen, but so far not seen it (I think I have seen it catch a couple of bugs for code that did not have unit tests).

This again seems to be throwing the baby out with the bath water. Just because in some cases types can't be verified does not mean we should fully be without types at all. There are a myriad of ways to mitigate even this, Parse, Don't Validate comes to mind [0]. Type Driven Development is another way [1], as well as using runtime type checkers like Zod. This article by Kent C Dodds is a really good example of the latter, it covers everything you're talking about regarding unknown types [2].

> I would even argue that it may create a false sense of safety -- just think of the Mars satellite that crashed because some developer thought a number was in imperial units when, of course, it was in SI.

Actually, that sounds to me like just the opposite case. The dev thought it was in imperial units because they might not have known the type of said number. If the number was instead typed with `ImperialUnit unit = ...`, that issue might not have occurred. Now, if the unit value was inputted incorrectly by the programmer, that's a different issue, no amount of typing will fix a business logic typo. As well, if the satellite was fully untyped, issues like these would have occurred far more often, so taking a singular example as a damnation of an entire paradigm doesn't really work.

[0] https://news.ycombinator.com/item?id=27639890

[1] https://blog.ploeh.dk/2015/08/10/type-driven-development/

[2] https://www.epicweb.dev/fully-typed-web-apps