Because Typescript was designed to be a tool to write Javascript with type annotations at first place and nothing else.

Compiling TypeScript to JavaScript is essentially just removing the type annotations. Compiling to a bytecode VM would be orders of magnitude more work, especially since TS is defined to have exactly the same runtime semantics as JavaScript.

Unfortunately, it's not.

TS classes are not JS classes, TS has it's own implementation of async/await, etc. Just check any compiled TS code and you'll see it. It's very frustrating when you want to quickly patch a bug in 3rd-party library.

TS can target older versions of JS without modern features, just like Babel. If you target a more recent latest release of ES, the emitted JS should be pretty much the same as the source TS, just without type annotations.

You are most likely looking at code which has been compiled to target an older ES version which doesn't have these features.

Web assembly is very low level. It's not a VM, there are no strings. It's designed to model 'assembly' style instructions.

To do TS on JS you'd have to build a VM on top of WA.

And that would probably be pointless of course.

Idk man. webassembly.org — the site authored by the inventors — literally starts with “WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.”

My answer is correct.

Yes of course WASM is a VM of some kind, that should be obvious enough i.e. people are not running machine code in WASM.

My response indicated that if you want to run JS on WASM you have to build another VM on top of WASM (which you indicated is already a VM, sure).

To do JS in WASM you'd have to build something like V8 (a VM) on top of WASM.

Actually, they might. It just a matter of creating a FPGA implementation.

It is a VM. Most VMs use High-Level Intermediate Representation (HIR or bytecode). WebAssembly uses a Low-Level Intermediate Representation. (LIR) A LIR is not an assembly.

Can TS be compiled directly to WASM? I don't think WASM and JS are 1:1 compatible, but I'm out of my depth here.

AssemblyScript initially targeted TS->WASM compilation, by only supporting a strict subset of the TS language. But at some point they dropped that idea and defined their own TS-like language. I don't know the reason for this, but my guess is that TS is too dynamic to just directly compile it to WASM?

Microsoft has done exactly the same on their MakeCode IoT compiler, using TypeScript and Python.

"MakeCode Languages: Blocks, Static TypeScript and Static Python"

https://makecode.com/language

It is very hard to generate good AOT code when dealing with dynamic languages, of any kind.

WASM cannot manipulate the DOM.

It can indirectly by simply calling the javascript APIs via bindings. That works well enough and is also how you can use things like webgl, openal and other browser APIs.

But they are also working on more efficient bindings.

This unfortunately introduces a lot of overhead and doesn't scale well for larger applications. WebGL calls are already incredibly slow compared to native, and the trampolining between WASM and JS world adds on top.

When WASM got released (around 2017), there was already that discussion to allow direct bindings without a JS roundtrip, but AFAIK there is still no actual implementation for this in any browser.

WebGL is slower than native mainly because of the additional security-validations compared to a native GL driver, e.g. it cannot simply forward calls into the underlying 3D-API but instead WebGL needs to take everything apart, look at each single piece to make sure it's correct, reassamble everything and then call the underlying 3D-API (roughly speaking).

The calling overhead between WASM and JS is quite negligable compared to that (at least since around 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...).

Another problem is that WebGL relies on garbage collected Javascript objects, but this problem can't really be solved on the WASM side, even with the "anyref" proposal (this would just allow to remove the mapping layer between integer ids and Javascript objects that's currently needed).

Doesn't seem to stop MS with Blazor (.Net), Rust, and a few others from doing this. Also, there are plenty of games running in web assembly using bindings for things like WebGL and openal via similar bindings. As far as I know the current situation is pretty workable already and getting better. E.g. garbage collection is coming pretty soon.

I guess it depends on what you are doing. For most people doing web assembly, the point is avoiding dealing with/minimizing the need for interacting with javascript. But still, it seems there are some nice virtual dom options for Rust: https://github.com/fitzgen/dodrio that are allededly fast and performant (not a Rust programmer myself).

Can anyone provide any pointer or update on this. I remember reading it is coming for the past 3 years and never heard anything. Google Search doesn't show any useful results.

TS predates WASM by years and WASM is also not adequate for executing TS.