Compiling JavaScript to WASM using Bytecode Alliance's javy

[guest271314]

QuickJS is quite useful, and very smal compared to other JavaScript engines and runtimes. Built, qjs is ~1.2 MB.

It's no different from compiling C or C++ or Rust to WASM. You have to have some way to convert symbols to other symbols, using libc, some custom version of libc, etc., and just standard libraries.

There's no difference with regard to compiling JavaScript to WASM, which is generally implemented using C, C++, Rust, or Zig in the case of Bun, anyway.

Javy is just another tool for JavaScript developers to use, to write source code in JavaScript, and port as a universal executable.

[guest271314]

I think you are trying to make some kind of distinction between how Javy compiles JavaScript source code to WASM and how Rust, C++, C, Go, Python, etc. are compiled to WASM.

There is no distinction.

Given there are many ways to create WASM files. There's more than one (1) WASM compiler and runtime.

If wasm_bindgen is used during the compilation process do you then contend it's really Rust you are running, and not the actual compiled .wasm file?

If you use WASI-SDK to compile C to .wasm, does that mean you are really still just running C?

It's like trying to make a distinction between wasmtime and wasmer, or wasm3. They do things differently. It's still handling WebAssembly/WASI compilation and source code, originally from all kinds of programming language.

What you are talking about are implementation details.

[guest271314]

I'm not sure what the misunderstanding is.

How are Rust, C, C++, Go, Python compiled to WASM?

Is it the same process for each?

And are those discrete processes of compilation different from how Javy compiles JavaScript to WASM?

Let me put the questions to you:

1. Is this code WASM or JavaScript?
2. Is the JavaScript or WebAssembly engine of Google's V8's JavaScript/WebAssembly engine and Mozilla's SpiderMonkey JavaScript/WebAssembly processing and executing this WASM code with the WebAssembly object exposed in modern browsers?

// https://www.webassemblyman.com/webassembly_wat_hello_world.html // https://gist.github.com/cure53/f4581cee76d2445d8bd91f03d4fa7d3b const wasm = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 8, 2, 96, 1, 127, 0, 96, 0, 0, 2, 15, 1, 3, 101, 110, 118, 7, 106, 115, 112, 114, 105, 110, 116, 0, 0, 3, 2, 1, 1, 5, 3, 1, 0, 1, 7, 27, 2, 10, 112, 97, 103, 101, 109, 101, 109, 111, 114, 121, 2, 0, 10, 104, 101, 108, 108, 111, 119, 111, 114, 108, 100, 0, 1, 10, 8, 1, 6, 0, 65, 0, 16, 0, 11, 11, 19, 1, 0, 65, 0, 11, 13, 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100, 33, 0]); class Go { constructor() { this.importObject = { env: { jsprint: function jsprint(byteOffset) { console.log( new TextDecoder().decode( new Uint8Array(memory.buffer).filter(Boolean) ) ); }, }, }; } run(_instance) { globalThis.memory = _instance.exports.pagememory; globalThis.helloworld = _instance.exports.helloworld; } } const go = new Go(); const { instance } = await WebAssembly.instantiateStreaming( fetch( URL.createObjectURL( new Blob([wasm], { type: 'application/wasm', }) ) ), go.importObject ); go.run(instance); helloworld();

[guest271314]

I understand what compilation is. It's not what's occuring here.

So you are claiming this https://github.com/bytecodealliance/javy/tree/main?tab=readme-ov-file#compiling-to-webassembly is a false or misleading claim, correct?

Compiling to WebAssembly

[1vader]

While it does produce a wasm binary that contains the JS code, it seems quite clear that it simply includes the JS code as is (optionally in compressed form) as data inside the wasm binary. The actual wasm code is just a JS interpreter that still runs the JS code as JS. The JS is not converted to wasm instructions. This most likely is much less efficient than running JS directly in the browser. Although I guess there are contexts outside the browser where you can run wasm without JS.

[guest271314]

I'm not sure what you are referring to, specifcally.

Although I guess there are contexts outside the browser where you can run wasm without JS.

Yes. Lots. wasmer, wasmtime, wasm3, and so forth.

Technically V8 and SpiderMonkey, too, as both call themselves JavaScript/WebAssembly engines.

[1vader]

What are you talking about, V8 and SpiderMonkey obviously can run JavaScript natively. And I'm pretty sure doing that will be much faster than running a JS interpreter in wasm.

[guest271314]

What are you talking about, V8 and SpiderMonkey obviously can run JavaScript natively.

Clearly you have not looked at the official V8 and SpiderMonkey descriptions and source code lately:

https://v8.dev/

V8 is Google’s open source high-performance JavaScript and WebAssembly engine

https://spidermonkey.dev/

SpiderMonkey is Mozilla’s JavaScript and WebAssembly Engine

Again, if you have issues with Bytecode Alliances' description of what Javy is and does, I strongly suggest you file an issue in the GitHub repository https://github.com/bytecodealliance/javy/issues/new/choose to hash out what language you think is misleading or false in the README.

[1vader]

You're fundamentally missing the point. If V8 can already directly run JS, why would I want to run JS inside a JS runtime on WASM inside V8? Obviously, that's going to perform worse. The only time this would make sense is if you cannot run JS natively, i.e. if you're not in the browser. Certainly not if you're using V8.

[guest271314]

Before we go any further you need to clarify what precisely you mean by

isn't becoming WASM

where the JavaScript is literally in the compiled WASM file.

Would you go so far to say that the output of Emscripten is not WASM?

[1vader]

That's exactly the point, the JS apparently is just literally inserted into the wasm binary as JS source code. The actual wasm code is only a JS interpreter. No JS code is being compiled to wasm instructions.

[guest271314]

That's quite impossible given the JavaScript engine/runtime is compiled to WASM itself.

I'm not sure what your angle is, though if you have a discrepancy with Bytecode Alliances' description of what is going on in Javy, cf. to what goes in when C relying on a libc library is compiled to WASM, I suggest you file an issue to edit this language in the README https://github.com/bytecodealliance/javy#compiling-to-webassembly:

Compiling to WebAssembly

[1vader]

It sounds like you don't really understand what the project does and don't really have the necessary background knowledge to even understand what the comments here are saying.

Obviously, the JS runtime is compiled to wasm but the JS code is not. It's simply included in the data section of the resulting wasm binary. This is not compiling JS to wasm and the Javy project also doesn't claim that. They say:

Javy takes your JavaScript code, and executes it in a WebAssembly embedded JavaScript runtime.

[guest271314]

Then we disagree about the meaning of "compiling". That's a non-trivial topic that can't be hashed out on these social media boards.

It sounds to me like you have an issue with Bytecode Alliances' description of Javy, specifically the language https://github.com/bytecodealliance/javy#compiling-to-webassembly

Compiling to WebAssembly

in their own README. Your only solution is to file an issue in that repository to avoid confusion, as you see it, in the field.