# Frequently asked questions
Questions that may arise before, at or after this point. so if you're wondering about one thing or another, here it is:
|Compute-heavy algorithm||Use WebAssembly|
|Games||Use WebAssembly for CPU-intensive parts|
|WebGL||Depends how much of it is calling APIs. Probably both.|
Or: WebAssembly is great for computational tasks, stuff with numbers, but still needs some time to become more convenient and efficient at the same time where sharing numbers between the module and the host is not enough.
Not always, but there are use cases especially well-suited for it, like creating a Game Boy emulator by making use of its low-level capabilities, essentially emitting raw WebAssembly using a nicer syntax. But pre-existing TypeScript code doesn't magically become faster just by compiling to WebAssembly, especially when making extensive use of managed objects that require memory management and garbage collection (this has its cost in every language) or talking to the host in structures that WebAssembly isn't currently good at, like strings or more complex objects. Low-level code (just functions, numbers, math and hard work) is always the best choice when all you care about is raw performance.
# How does AssemblyScript compare/relate to C++/Rust?
First and foremost: Both Emscripten (C++) and Rust have very mature tooling to compile to WebAssembly and are made by the smartest people in this field. Also, both can make use of compiler infrastructure that has been created by many individuals and corporations over years. In contrast, AssemblyScript is a relatively young project with limited resources that strives to create a viable alternative from another perspective.
More precisely: AssemblyScript is putting anything web - from APIs to syntax to WebAssembly - first and then glues it all together, while others lift an existing ecosystem to the web. We believe that both approaches are fantastic, and fortunately for us, there is Binaryen, a compiler infrastructure and toolchain library for WebAssembly primarily created by the main author of Emscripten, that we can utilize to considerably close the gap. We are very thankful for it. Binaryen is not as optimal for AssemblyScript-generated code as it is for LLVM-generated code in a few cases, but it's already pretty good and continuously becoming better. It's also noteworthy that AssemblyScript is still behind in specific language features, but we are working on that.
In short: AssemblyScript differs in that it is new and tries another approach. It's not as mature as Emscripten and Rust, but there is something about the idea that is definitely appealing. If you find it appealing as well, AssemblyScript is for you.
# Will AssemblyScript support all of TypeScript eventually?
This is an open question. While there are WebAssembly proposals specifically aiming at improving interop, not all of them consider excellent interoperability between WebAssembly and the existing web platform as important as we do.
If you are interested in these aspects, feel free to join us in the respective spec discussions to inform the process.
# How can I help?
There are various ways to help. AssemblyScript is an open source project, and everyone is welcome to contribute code (opens new window), documentation (opens new window), or time (opens new window). We also have an OpenCollective (opens new window) for those preferring to help the project out with a sponsorship.