[JoeNr76]

This was my main reason to switch to mainly front-end: to get away from clunky, badly written C# and Java back-end programming. 2/3 of a code file are just the coder wrangling the OOP typesystem instead of just coding the functionality that is needed.

I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types.

But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular

[wizzwizz4]

Strict type checking does make your code bulletproof. Unfortunately, TypeScript doesn't provide anything close to that. It's easier to mask errors with TypeScript than auto-detect them. Its strict typing should be considered hints for the programmer.

[JoeNr76]

Real strict type checking (as in, eg, Haskell ) does indeed make your code resistant to a certain type of bug. But the kind of type checking Typescript gives you is mostly useful as autocomplete.

(and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)

[wizzwizz4]

At runtime, you can pass primitives to a function that expects a very specific DOM object (say), and it'll just plough on ahead like JavaScript does, until you get an exception that nothing catches because FooFunction doesn't raise any exceptions, and everything breaks.

Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).