Deno: WASM instead of Typescript

[olanod]

I guess it's a bit late now, but couldn't have not only the runtime be written in Rust but also every other API and be compiled to WASM? in the longer term it would translate in faster start-up times better more predictable performance. I imagine the community could later create a WASM version of the std and any other API right? or are there major blockers that make it hard to do?

[lucacasonato]

This is not what WASM is for.

[olanod]

How is it not a legitimate usage of WASM? What is the one valid usage you have in mind? I don't think there is one specific task WASM is meant to do, is a very general purpose low level virtual machine that a few years down the line will be available and running absolutely everywhere, embedded hardware, operating systems, cloud, blockchain, docker replacement, you name it. The web and being JavaScript's sidekick was a facade, this bad guy had mayor plans from the beginning, is far from reaching its full real potential.

As a Deno user what do you care if the standard library or any library is written in one language or another, it could have all been native Rust to get the best performance possible but then you suffer from a bloated runtime, to keep it slim and not force its users to use the std Deno can provide it in a format that is very portable like JS/Typescript which it happens to support, but there is also WASM that will give you smaller modules that you'll be waiting less to download, will be much faster to parse, compile and optimize and will give you better or at least more predictable performance.

Perhaps in its current state WASM is a bit rough around the edges and not ideal to integrate, a Rust library for example will be compiled using wasm bindgen that wraps the binary with some JS glue that loads the WASM binary and gives you higher level API, but those issues will quickly fade when say *.wasm imports are allowed and interface types or equivalent gets standardized, most likely you'll end up using import maps and not even managing your dependencies directly so little you'll care what language your dependency is written with when you import foo from 'super-foo'.

[kitsonk]

Duplicate of #5961, #1980 and a few other suggestions like #5591.

Running Rust as compiled Rust will always be faster than run Rust compiled to Web Assembly. It is only something you do when you can't run Rust as part of the binary. For code authored in JavaScript, Web Assembly is not a good target, as JavaScript is a GC'ed language (plus a lot of other stuff) which all have to be re-implmented in WASM and then in theory better than V8.

[olanod]

I doesn't look clear to me how this is a duplicate of those issues but .. :man_shrugging:
It's not about compiling TS/JS to WASM, but mostly about not using TS/JS and only Rust compiled to WASM, at least for the std lib and important libraries.

[kitsonk]

Rust compiled to Web Assembly would run slower than Rust. Writing all of the std in Rust is not ideal, as it is hard to make effective JavaScript/TypeScript interfaces in WASM. It also makes contribution complex, and it is cumbersome. Moving critical hot paths to Rust or Web Assembly makes sense, which was just done with hashes: https://github.com/denoland/deno/blob/master/std/hash/_wasm/src/lib.rs but does not require a meta issue to be open for that. If there are specific hot paths you wish to contribute or you think need to be moved over, then a specific issue is far more appropriate.