[cryptica]

>> Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore

That should be at the top of every page on the TypeScript documentation website. It would save developers so much suffering.

>> All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at the same time.

I'm still looking forward to the TypeScript version when they invent dynamic typing and enforce it at compile time.

I have similar experiences. What I've found is that a team which can build a high quality application in TypeScript is generally capable of building an even higher quality application in JavaScript in half the time and with better, higher quality test coverage.

>> I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly. Good luck with it anyways.

I look forward to this glorious day. Short live TypeScript!

[sli]

I do find it rather strange that strongly typed code with no errors, that builds correctly, can fail at runtime due to type errors. My JS oftentimes ends up nicer than my TS because I don't have pages of, basically, type-level administrative work.

I don't have this experience at all in other strongly typed languages, including very strong ones like Haskell/PureScript. The types there just work for me.

[cryptica]

This can happen if handling data from a remote client. Type checking does not happen at runtime so you still need to do your own schema validation even with TypeScript. So IMO it adds almost no value.

[jimmyspice]

in which case your API layer should validate the data at runtime so that it only actually returns type T as it claims. then you are back to soundness