[kingdomcome50]

> I see massive bizarre and difficult to grok type declarations that grow in excruciatingly byzantine complexity just to satisfy the compiler for non-trivial flexible function definitions.

Is this better or worse than no type definition? Whether or not a type is defined it is still consumed. I can totally understand that sometimes types can get a bit unwieldy, but those are the exact scenarios that save future-you from introducing a bug because you didn't know what a variable is (and is not). At the very least it may be an indicator of poor design/code smell when the above occurs.

I hear you on compilation/build process woes. That's the fairest criticism against TypeScript IMO (though it's a fairly weak argument as well).

Most of your other critiques aren't really levied against TypeScript, rather, your work environment (not that it makes working with TS any less painful!).

[claytongulick]

What I'm referring to is non-trivial function definitions.

Things with optional parameters that can accept a wide variety of types, async callbacks and async variadic return types.

The hoops you need to jump through to make the compiler happy are absurd.

[kingdomcome50]

Functions like the ones you are describing probably shouldn't exist!

I have no doubt that a sizable portion of these functions' bodies is dedicated to figuring out which type each of our input variables represent (from our wide variety). So now instead of having our editor/compiler help us out, we are now actually writing code to figure it out ourselves... this is more absurd (and less efficient).

And FWIW, using union types makes it trivial to denote that a function can accept a wide variety of types in a type-safe way. But guess what you will be doing first thing in the function body? Discriminating that union!

[jestar_jokin]

Sounds like a problem with some API trying to make everyone happy.

Could be avoided by having more functions, one for each case.

(Only if you control the code, of course.)