Could you please elaborate on how TypeScript's type system is better than C#?

I disagree with OP, but two interesting corollaries of TS type semantics are its strong type inference and structural typing:

Const x = [{x: 3, y: "hi"}, {x: 9, y: "bye"}];

Automatically gets you x: "Array of {x : number, y: string }". And if you declare the same type somewhere else, as long as they're "structurally equivalent" (i.e. same x and y types) you can actually use them interchangeably. You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.

This lets you do some funny stuff like"subset type detection ": https://gist.github.com/hraban/66c1778cdd31868034b12db93fcce...

All in all, it's more of an oddity than an actual strength, if you ask me. It's necessary to emulate JS semantics, but I wouldn't consider it an advantage in a new language.

> You can't do that e.g. with c#, where one class will never be exchangeable with an unrelated class , no matter how similar the definitions.

Agreed. Duck typing is a killer feature. I can't say how many time's I've rolled a new class for no reason other than data structuring, which would have been far preferable as something just defined inline.

Mostly, for me, it comes down to union types, intersection types, the ability to disallow implicit nulls (meaning null must be declared as a valid value at the type level, and therefore cannot creep in unexpectedly), string literal types, discriminated unions (most of the good stuff from algebraic data types), and index types.

All demonstrated here: https://www.typescriptlang.org/docs/handbook/advanced-types....

The result is a very nice, expressive way to state your types and get maximal benefit from the type checker.

It could be another target for TypeScript though.

Typescript is designed to be compiled to JS. WASM is designed for staticly compiled languages. Even if there is GC and DOM access through WASM, Typescript will be better off to run for the natively JIT optimized JS path.

Really?

Anders Hejlsberg is in charge of TypeScript and a apt compiler architect with a proven track record(turbo pascal, delphi, .net/C#).

Sure, Anders is great but this not so easy. Basically you would have to re-implement all the features and optimizations of current JS-Engines. In WASM you are restricted to the given (statically-typed) opcodes, while a JS-JIT has more knowledge about program semantics and can thus apply optimizations more easily. In addition the JIT can also make use of hand-written assembly if it is needed for best performance.

I think JRuby does a similar thing for Ruby and Java Bytecode. TruffleRuby shows that it is possible to be faster, they do not compile to bytecode and use their own compiler.

Sure, but all else being equal, a statically typed language will always be faster than a dynamically typed one, because you can do way more optimization at compile-time rather than run-time. So you're right in that JS is pretty darn fast, but it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler.

Sure, but AFAIK TypeScript is not generally fully statically typed. You could just rename a .js file to .ts and call that TypeScript. Please correct me if I am wrong.

There are some dynamically typed languages like Python or Dart that allow (or are in the process to allow) type annotations. But all these languages I know about claim that type annotations do not help performance. I guess you could define a fully statically typed subset of TypeScript that allows you to compile it to fast WebAssembly bytecode. But that would probably also mean to change some semantics: see int vs double for numbers in JavaScript.

The only reason type annotations in those languages don't increase performance is that they compile down to JS, which is dynamically typed, so all static type information is lost. But you're right, you would either have to annotate everything with types, or re-implement the JS runtime in WASM in order to gain any benefit from it. The most feasible option would be to target a fully-typed subset of TS, which may or may not be practical.

I am not sure what you mean? Both Python (PyPy) and Dart have a JIT (yes, you can also compile Dart to JS), so they don't lose type information in those VMs. See what the PyPy-Devs have to say about type annotations and performance (they have a faq entry for that!): http://doc.pypy.org/en/latest/faq.html#would-type-annotation... And here is what the Dart devs have to say: https://www.dartlang.org/faq#q-but-dont-you-need-sound-typin...

Your claim was "it probably wouldn't take that much effort to surpass JS performance with a custom TypeScript -> WASM compiler"

I guess you basically have two options:

1) Implement a JS-Engine on top of WASM. Which is a lot of work. But what could you do to get better performance than current JS-Engines? Every optimization you can implement on top of WASM, you can also implement for native JS-Engines. Quite the contrary it is even harder, since you are an abstraction layer higher and can only make use of WASM opcodes.

2) Define a fully-statically typed subset of Dart and compile to WASM. You could sure do that, but don't forget about e.g. the ubiquitous number type in JS/TS. You may have to use double (almost) everywhere if you want to match semantics of JS. How many non-trivial TypeScript programs could such a subset run successfully? I assume not a lot.

I don't see how you could write a TypeScript to WASM compiler without much effort. Care to explain?

F# has an even better type system :)