TS has nice features to avoid js bombs but all JS 'bad code' is legit by definition (JS superset). TS is super nice compared to JS but it is NOT excellent Lang.
> all JS 'bad code' is legit by definition (JS superset)
That's not true. There's a lot of JS code out there that is certainly not legit in TS. Probably the shortest example is `1 === "a"` which produces a TypeError, but if you use TS at all you'll understand that a lot of bad patterns are made painful or impossible thanks to the strict type system.
== versus === and all the other weak typing wats, undefined type still exists in typescript, no integer type, UTF16 strings are the ones coming to my mind and I don't even program in JS/TS
In a word, "correctly". The result of an expression with + or isNaN() will be of whatever type the JS spec says it should be. This is one of the less frequently touted, but more useful aspects of TypeScript - the lib.d.ts file acts as a partner to explain to you how the built-in JS type system actually works without you having to memorize or look up everything in docs.
For == vs === use a linter, same as you would for warts in other languages.
What's the issue with undefined - is it that you would use null instead?
I don't feel a need for integer type, but maybe that's because I grew up on JS. Integers feel like warts to me in a lot of cases, ie why would 2/3 == 1?
2/3 === .666666666666666629659232512495 is probably worse, because it can seduce you into thinking it's accurate. Why is `2 / 3 * 3 === 3`, but `1 / 3 * 3 < 3`?
JS's floating-point-or-bust, combined with some weird Math semantics, makes it challenging to write numerically correct functions.
Floating point tends to break all sorts of assumptions. For languages without static types, bignum integers and distinct operators for truncating vs FP division is probably best. This is how Python 3 works, plus Haskell and SML (with static types).
TypeScript addresses many of JavaScript's type-related issues but retains other JavaScript insanity: bizarre array semantics, Unicode ignorance, no integer arithmetic, regex facepalms, Math weirdness, etc.
The root of the wtf is how Arrays play double-duty as both indexed and associative. The ES spec says that if you modify a property of an array object, the implementation must check if the (necessarily String) key changes after being round-tripped through a UInt32 conversion. If not, the key is a special array index that bumps the length; otherwise the length is unaffected.
var arr1 = []; arr1[2147483648]=1; // arr1.length == 0
var arr2 = []; arr2[2147483647]=1; // arr2.length == 2147483648
var arr3 = []; arr3[-1]=1; // arr3.length == 0
This is JavaScript so naturally .length is settable:
var arr = []; arr.length = 3; // works!
But implementations are still required to distinguish between keys that are undefined and keys that outright don't exist:
var arr = []; arr.length = 3;
arr[0] = arr[2] = undefined;
for (key in arr) print(key); // 0, 2
And of course you can set whatever random associative array property you like:
var arr = []; arr[1] = true;
arr[3.5] = false; // "works", .length is still 2
The intent is that array implementations may use efficient unboxed contiguous storage, but the spec requires that arrays may be sparse so it's still necessary to track which keys are actually set even if values are undefined.
Want to iterate an array's keys? There's no requirement that array indexes start at 0, and you may encounter random other keys from the array prototype.
Every time I see something like this, I stop and consider just how saner Lua is, even though in many ways it adopted similar approaches (e.g. associative arrays doubling as regular ones).