No, you're making a good point, but my meaning was that TypeScript is a language that is always (and has always been) written as an improved, benefit-of-hindsight, good-parts-only language. It does of course allow any old JS to be used, but that has always been for the purpose of allowing code already written in JavaScript to be called from code written in TypeScript. No TypeScript project, library, or tutorial is ever written like old JS, so TS's allowance of old code that was already written as JS is like a C compiler's escape to assembly, where inline assembly is valid code handled by the C compiler but isn't really C.

Traditional JS with new features added, or traditional Node with new features added is the opposite case, where the old standard is being extended, unlike the TS or C+asm case, where the new standard has a mechanism for calling back to the old if necessary. (Deno could still be what I'm talking about even if they added a Node-emulation-library to allow it to call modules written for Node, but I have no idea whether such a thing is planned.)

Unfortunately, that's not a very accurate analogy. TS also inherits all of JS runtime semantics unchanged, and there's just as much if not more wrongness there.

I wish for a version of TS where I could have === automatically rewritten to use _.isEqual, that way [1,2,3] === [1,2,3] would return true.

In clojure(script) equality works this way. Values are compared and not instances. It makes the language a little bit higher level and more ergonomic. Love that feature.

Also, it's not like TypeScript is without its own set of legacy cruft that they haven't been able to let go (yet). Namespaces and decorators with old, deprecated spec come to mind.

I love TS as much as the next person but I don't think it's particularly good example to use here.

Know the language and use automatic linting to exclude the bad parts without effort. Here you go, Javascript/Typescript is suddenly a decent language too.