[MobiusHorizons]

When was the last time this caused a bug for you? My experience of moving from JavaScript to typescript is that it takes significantly longer to write many generic things because the types can’t really express the intended use as well. I will certainly admit that types help a lot at the boundaries between systems , or for catching errors introduced when changing code, but it’s not always a clear win for types, given how much more verbose, and less expressive the language becomes as a result.

[kqr]

We actually have science on specifically plain ECMAScript versus TypeScript, where the software written in the latter has 15 % fewer bugs. https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

But of course, the study does not account for if increased development time cancel out revenue gained from lower bug count. (And this will be a difficult problem in general, due to first-to-market effects etc.)

[wruza]

This is my experience as well. I have a side project in its prototyping state and tried to use typescript in it. The result was exactly what I was afraid of - the first half of a weekend spent on fine-tuning tsconfig and tsserver integration, the second half on type acrobatics and investigating wrong narrowing issues. No code was written that day. I have a decent experience with both typed and untyped languages to see pros and cons of typing and am consciously choosing untyped for the “development” phase.

[LudwigNagasena]

I agree with the first part (I generally hate the devops situation with JS, TS, nodejs, modules, etc). But I don't understand the part about type acrobatics. TypeScript's typing is robust to the point of being Turing complete, so you can express things that are generally not expressable in your typical typed language. And if TypeScript cannot pin down your types, it is probably a code smell. But you can revert to "any" at any time anyway, if you feel compelled to do some unidiomatic js trickery.

[wruza]

I’ve ran into situations where pretty obvious “if (typeof + condition)” chain over-narrowed a type so that further else-ifs were inferred as “never”. The logic was sound and triple-checked, I only struggled with convincing tsc that it’s okay. Sure, it was my fault somewhere in my types and not in typescript, but the progress doesn’t care which part of a development site fails or spends too much time in research.

unidiomatic js trickery

  type Foo = undefined | false | Unit | Foo[] | FooObject

This was a part of the issue, afaiu. FooObject being “partial” either fell through obvious typeof guards, or removed other essential types from a branch, depending on what I tried. I ~understand why the issue persisted, but had no clear way to tell tsc what I mean there. The perspective to meet a similar issue in a much more complex case feels unpleasant.

While types make intents formal (which is a pro), they require to specify irrelevant edge cases. Dynamic typing serves as “code is law”, and when you meet an edge case in the wild, it’s much easier to explain it than to formalize.

I also remember many cases of prototyping in other typed languages and it never felt “focused on the job” to me there either, even when (or despite?) a type system wasn’t turing-complete.

Also, my best hope for typescript was that it would allow me to create type-only “header files”, which would serve as a source of truth and a sort of auto-validated documentation. It turned out that forwards are not first class citizens in ts, and it was sunday evening already, so I gave up.