At the moment the easiest way would probably be to write some glue code in JavaScript (see Let’s write Pong in WebAssembly https://medium.com/@mbebenita/lets-write-pong-in-webassembly...).
[1] https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
TypeScript was used as an example of a well-known language that currently is transpiled to JavaScript. I am not saying that TypeScript will surely be compiled to WebAssembly, just that it could.
TypeScript is designed for development of large applications. It is a superset of JavaScript both because this facilitates learning, but also because there was really not an alternative. In the end you had to compile to JavaScript. It is not hard to imagine a language with the same objective of TypeScript that is compiled to WebAssembly. Furthermore, if TypeScript was compiled to WebAssembly you could use it wherever there was a platform for the WebAssembly format. So if somebody created a project to consume WASM binary files and execute them from within .NET assemblies[1], you could use TypeScript outside the browser and node.
[1] https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFut...
I apologise. I'm just… rather surprised at such an idea.
> It is not hard to imagine a language with the same objective of TypeScript that is compiled to WebAssembly.
It is not hard to an imagine a strongly-typed language targeting WebAssembly, sure. But TypeScript is not that kind of language. TypeScript is just JavaScript, and JavaScript, as a highly dynamic language, is a very poor candidate for the kind of ahead-of-time compilation to a low-level target that WebAssembly was made for. I mean… it could, technically, be done, but why would anyone do so? The result would be bigger and slower than normal JS.
I agree with this. Mentioning compilation of TypeScript to WebAssembly shows some misunderstandings of both of these technologies. WebAssembly was designed to run code already written in some low level language like C/C++ because running already written software in a browser is easier than rewriting it. Of course you can compile Rust into WebAssembly but that was not a reason for why WebAssembly (and it's predecessors, asm.js, PNaCL) were conceived.
On the other hand TypeScript makes JavaScript programming easier for when the app becomes too big to maintain without tooling.
This doesn't look like traditional TypeScript to me. The explicit loads/stores give away the whole trick.
https://github.com/AssemblyScript/assemblyscript/blob/master...
And it requires JS twice the size of the TypeScript to actually use the output generated by AssemblyScript. I personally don't see WASM a valid target for AssemblyScript for another year or two, until either the gc or host-bindings proposals lands.
In theory, you wouldn't have to parse JavaScript, when delivering WASM, which should lead to faster startup times.
I am a TypeScript user and in the article he states:
For instance, instead of compiling TypeScript to JavaScript, its developers could now compile to WebAssembly.
Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness (maybe some day).
But now with this in my toolbelt. What occurs? What does it mean? If I have a particle simulation in TypeScript on Canvas using Shaders... Now I compile to WebAssembly, but now what? Can I still access Canvas or is Canvas like a 4th dimension? IF I can't use Canvas, how do I render to screen?