Open feynon opened 11 months ago
The first two make sense, for use-cases outside browsers. The last one is somewhat blurry to me. I'm trying to understand it Why would I compile my code to WASM as a frontend developer for frontend usecases? What benefit does that give me when compared to the traditional way?
In frontend projects, it's very common to build some CPU intensive logic to WebAssembly to get better performance (e.g. photoshop on the web).
Currently some statically typed languages such as C/C++/Rust can be successfully compiled to WebAssembly and work well, but the frontend developers are not familiar with these languages. Wasmnizer-ts
provides a new choice: the frontend developers can write TypeScript and compiled to WebAssembly without learning a new language.
Got it, understood. Reminded me of this effort: Typescript as fast as Rust: Typescript++ by Zaplib people, which is discontinued now and discussed in their post mortem blog.
And how does it compare to AssemblyScript? I get that AssemblyScript is a different language ie it has its own compiler frontend as well, but it is also advertising itself of being a subset of TypeScript. Who and why anyone would choose wasmnizer-ts over AssemblyScript?
Hi, the
Wasmnizer-ts
brings a subset of TypeScript to WebAssembly, it can be used in many areas as long as they need programming capabilities, some typical scenarios include:Wasmnizer-ts
leverage WasmGC, so we don't need to compile a whole language runtime inside WebAssembly, this will make the generated wasm module very small;Wasmnizer-ts
brings a new choice for developers;Wasmnizer-ts
doesn't introduce new language, it's just like a new backend for TypeScript, so frontend developer can use WebAssembly without learning C/C++/Rust;