Yes. All JS code – including recent ES* flavors – is valid TypeScript.

This is true of syntax, but it’s not true of the language semantics. There is plenty of perfectly valid JavaScript that isn’t valid TypeScript, so integrating TypeScript into the ECMAScript standard would require something similar to ES5’s “use strict”.

I can’t find the link which details this right now, but I believe there are/were some cases where Flow’s syntax isn’t strictly a superset of JavaScript (to do with generics and comparison operators). I’m not sure whether TypeScript has the same problem or not.

Almost. This is valid javascript.

    [1].push("foo");

TypeScript code can be transpiled and executed even if there are type errors (just like how a linter doesn't stop you from running your code), so in that sense, it's also valid TypeScript.

Technically typescript is a strict superset of JS, but yes

Technically technically, it turns out that no it's not. I recently realized that `a<b>(x)`, `a<b,c>(x)` and variations mean something completely different in TS than they do in JS.

And that’s exactly why Rust has the turbofish (a :: before the <), to resolve that syntactic ambiguity. TypeScript could have resolved it by requiring a . before the <, but it didn’t, and so you can devise contrived cases like this where it differs from JavaScript.

Is that denoting generics? Can you give an example?

Yeah, it's the syntax when calling a generic function, e.g. `Array.of<number | null>(1, 2, null);` has return type `Array<number | null>`. You usually don't need to specify the type since TypeScript can figure it out, but sometime's it's necessary to specify it explicitly.

TypeScript compiles `a<b>(x)` to `a(x)`, which is a function call, but when run as plain JS, `a<b>(x)` is a less-than and greater-than comparison between a, b, and x.

That's interesting and so obvious now that you mention it. Thanks for the clarification.