Hacker News new | ask | show | jobs
by zzo38computer 3280 days ago
I like the idea of WebAssembly too; it is another kind of VM code. However, is there a C API to WebAssembly? Having a JavaScript API that is usable in both HTML and Node.js (and could easily be added to any other JavaScript too) is good, but a C API can also help (and I have written on some file on my computer what are some ideas for making a C API).

(I did not read the linked document much though, but only the official FAQ. However I do think you would not use WebAssembly all the time, but it can be helpful in some cases, including wanting VM codes.)

2 comments

It's like asking "is there JavaScript API to JavaScript".

WebAssembly is a portable instruction set, a simplified CPU.

The main use case for WebAssembly is compiling C/C++ code to that instruction set using emsscripten, which is a clang-based C/C++ compiler that emits WebAssembly modules.

Depending on how you look at it, the answer to "is there C API to assembly?" is:

a) yes, that's the first API there ever was and it's the main API

b) the question doesn't make sense. C/C++ is compiled to WebAssembly, there's no API to it. You could imagine a system that would allow using WebAssembly modules from native C/C++ code, where you would need a C/C++ bridge to executing WebAssembly functions (similar to JavaScript bridge for calling WebAssembly functions), but this is not really why WebAssembly exists

b) is what I meant. I know that would not have been the original intention but I still think it can be useful in some cases, and there does not seem anything wrong with it. (It clearly wouldn't be for static linking WebAssembly codes with C codes, like what you might do with JavaScript, although it can have different uses.)
DOM manipulation isn't currently supported, for now you will need to provide a javascript layer between the C code and DOM. Its in the roadmap to create these interfaces.

Web assembly is better suited for CPU intensive tasks which you would want to offload from javascript but keep on the client.

I think that DOM manipulation should not be a part of WebAssembly, although the other way around may make some sense, where for example, the "window.wasm" property might be a WebAssembly module for accessing the HTML DOM (otherwise the module is not included and the WebAssembly code is sandboxed and cannot access DOM). If the WebAssembly module is loaded directly using a "script" tag in a HTML document, then it can automatically include the HTML DOM module.
Its inevitable that all of those who want to replace javascript will push facilities into the web assembly spec to remove javascript from the equation.