4 ms·

Is JS a strict subset of TypeScript?

by bauerd 8y ago

steadicat 8y ago
Yes. All JS code – including recent ES* flavors – is valid TypeScript.
- recursive 8y ago
  Almost. This is valid javascript. [1].push("foo");
  - alangpierce 8y ago
    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.
- thomasfoster96 8y ago
  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.
tazard 8y ago
Technically typescript is a strict superset of JS, but yes
- lhorie 8y ago
 Technically technically, it turns out that no it's not. I recently realized that `a(x)`, `a<b,c>(x)` and variations mean something completely different in TS than they do in JS.
 - spraak 8y ago
 Is that denoting generics? Can you give an example?
 - alangpierce 8y ago
 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(x)` to `a(x)`, which is a function call, but when run as plain JS, `a(x)` is a less-than and greater-than comparison between a, b, and x.
 - tazard 8y ago
 That's interesting and so obvious now that you mention it. Thanks for the clarification.
 - chrismorgan 8y ago
 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 JS a strict subset of TypeScript?

by bauerd 8y ago

Is JS a strict subset of TypeScript?

steadicat 8y ago

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

recursive 8y ago
Almost. This is valid javascript. [1].push("foo");
- alangpierce 8y ago
  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.
thomasfoster96 8y ago
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.

tazard 8y ago

Technically typescript is a strict superset of JS, but yes

lhorie 8y ago
Technically technically, it turns out that no it's not. I recently realized that `a(x)`, `a<b,c>(x)` and variations mean something completely different in TS than they do in JS.
- spraak 8y ago
 Is that denoting generics? Can you give an example?
 - alangpierce 8y ago
 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(x)` to `a(x)`, which is a function call, but when run as plain JS, `a(x)` is a less-than and greater-than comparison between a, b, and x.
 - tazard 8y ago
 That's interesting and so obvious now that you mention it. Thanks for the clarification.
- chrismorgan 8y ago
 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.