[scubbo]

> If you think adding types doesn't add much value then typescript may not be for you. In my experience, types are defined once then provide a lifetime of value

You have misunderstood the OP. The full paragraph is:

>> I want to skip over the static typing benefits argument, because I think it is well understood that static typing is a good thing and if we could bless JavaScript with a built-in and robust typing system then I don't think many people would be against that. My issue is with the amount of extra work it places on developers, much of it the "dumb" kind of work which can eat up hours and doesn't deliver all that much value.

Summarized: "I agree that static typing is a good thing. My issue is with the extra work (required to use TypeScript)...which doesn't deliver much value".

That is - they are saying that types deliver value, but that the extra busywork required to use and maintain a TypeScript project (e.g. keeping dependencies up-to-date) does not - and, by implication, that the overhead of this maintenance work is enough to make them question whether the (acknowledged) value of types is worth it.

(Note that I do not have a horse in the race as to whether the OP is correct in thinking that the overhead of TypeScript _as a language_ is greater than the value of the types. I haven't used it enough to have an educated opinion. But I am certain that you are responding to a point that was not actually the one being made)

[tgv]

But that is either not a properly formulated argument, or it denies the benefits of strict(ish) typing. You reformulate it so that one weighs out the other. That would only be the case for projects where you do more work integrating libraries than actual programming. That's something much easier to discuss (IMO), but is it what OP asked?

[raspberry1337]

>You reformulate it so that one weighs out the other. That would only be the case for projects where you do more work integrating libraries than actual programming.

No, the net gain with typing with static types as compared to without it, would be less than the increase of time spent with integrated libraries, rendering a total net loss.

[tmpfile]

That's fair. It appears his issue is more related to libraries with broken, undocumented types and typescript's opaque errors when an error occurs in said library. Unfortunately I think he's conflating typescript's role and a library with broken type definitions (I have no idea whether the type definitions he's had problems with are provided by the library or a community effort that may not keep pace with the official library). When the type definitions don't match the official library it can definitely cause a tremendous amount of frustration and make one doubt the usefulness of types.

[roberttod]

> Unfortunately I think he's conflating typescript's role and a library with broken type definitions (I have no idea whether the type definitions he's had problems with are provided by the library or a community effort that may not keep pace with the official library). When the type definitions don't match the official library it can definitely cause a tremendous amount of frustration and make one doubt the usefulness of types.

I am not trying to cast blame on any part of the TypeScript system. I have tremendous respect for the TS team and the problems they have had to solve to get this far. My point is, is it actually worth it? Whether people document their libraries is part of the equation, even if it may not be a direct responsibility of the TS team.

I thought things might get better as the community matures, but I am still dealing with issues that seem to sometimes outweigh what I get from it.

And I want to be clear as well that I mean to shed light on this thought and hear people's opinions. I am still open minded, and will continue to decide whether to use JS or TS depending on many variables whenever that decision comes my way. For personal projects I am currently in the boat that I would not choose TypeScript.