5 ms·

Why does TypeScript use javascript as a compile target and not web assembly?

• kevingadd 6y ago
  TS predates WASM by years and WASM is also not adequate for executing TS.
• aikah 6y ago
  Because Typescript was designed to be a tool to write Javascript with type annotations at first place and nothing else.
• FlyingSnake 6y ago
  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.
  • Schampu 6y ago
    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?
    • pjmlp 6y ago
      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 https://makecode.com/language It is very hard to generate good AOT code when dealing with dynamic languages, of any kind.
      • deleted 6y ago
        [deleted]
• qeternity 6y ago
  WASM cannot manipulate the DOM.
  • jillesvangurp 6y ago
    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.
    • Schampu 6y ago
      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.
      • jillesvangurp 6y ago
        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 https://github.com/fitzgen/dodrio that are allededly fast and performant (not a Rust programmer myself).
      • flohofwoe 6y ago
        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-and-webassembly-are-finally-fast-%F0%9F%8E%89/ 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).
• jariel 6y ago
  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.
  • crazypython 6y ago
    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.
  • dassurma 6y ago
    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.”
    • jariel 6y ago
      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.
      • pjmlp 6y ago
        Actually, they might. It just a matter of creating a FPGA implementation.
• paavohtl 6y ago
  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.
  • sesm 6y ago
    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.
    • sime2009 6y ago
      You are most likely looking at code which has been compiled to target an older ES version which doesn't have these features.
    • paavohtl 6y ago
      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.