This approach works great for NodeJS, but once I ran a test bundle I found that Webpack (and bundlephobia) included all the base64 “release” variants instead of lazy-loading the import statements. Bummer. I assumed this because Typescript on its own compiled import to Promise.resolve(require(…)), so it’s good to know that most bundlers will STILL get this wrong even if I’m emitting ES6 module import syntax. Yikes! I need to bite the bullet and start using Rollup to emit a slew of separate entry points. Oy veh.
Anyways A+++ would read again. This will save me 4-5 days of work stubbing my toe on bundlers and build system which is the Least Fun part of JS work.
You don't want to be in a position to ship code to production with binary code that could potentially be harmful
Off topic: Please don't mess up the way my browser scroll pages, it is infuriating
That said I generally agree with the premise, and even with sandboxing you should vet dependencies like these where appropriate if you can. A good example of this is something like an image decoder versus a database library (both of these being real scenarios; e.g. using a pure-Rust implementation of some SQL protocol.) The first one I probably wouldn't worry too about much, you're just giving it pixels in and getting pixels out. But the second one is likely worth a bit of scrutiny since it interfaces directly with a sensitive component.
For instance if you create a web mail application the code probably has access to all mails, can delete them, can send mail under the user's identity, ...
How relevant those scenarios are you have to evaluate.
If you compile yourself, you can verify the source to increase trust. If you just get the binary, you have to trust the vendor more.
pyodide.loadPackage("numpy");
pyodide.loadPackage("https://foo/bar/numpy.js");
# import micropip
micropip.install('https://example.com/files/snowballstemmer-2.0.0-py2.py3-none-any.whl')
conda-forge: "WASM as a supported architecture" https://github.com/conda-forge/conda-forge.github.io/issues/...
I'm still new to WASM, but I assume this functionality is part of the WASM runtime? (As opposed to a hook that's part of the Javascript part of Blazor?)
Most WASM libraries I’ve considered using (and the one I package myself) use an off-the-shelf Emscripten wrapper minified with Google Closure Compiler. This is annoying to audit compared to plain JS, but certainly doable with a few rename-symbol in your editor.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Doing a network request from C++:
val xhr = val::global("XMLHttpRequest").new_();
xhr.call<void>("open", std::string("GET"), std::string("http://url"));
Of course this can be thrown out of the JavaScript binding side so that it isn't there anymore, but the marshalling makes the API nice and so many emscripten users will use it, thus it's present, thus you have to trust the wasm library.
How complicated this is without emscripten i don't know, but even then I guess many people will need some marshalling for real life scenarios.
But, you're right, I forgot about this part of emscripten, my bad :) My use case was passing a 2Mb of image data to WASM, which was simple to do with just WebAssembly.Memory, so I didn't get the chance to use this part of the FFI (I used the part going in the opposite direction[1]). I don't know the details of the val implementation, nor the details of JS-side handling the calls, but the basic principle should be as I said: the only "things" you can pass between JS and WASM are numbers and linear buffers. To do anything above that you need support on the JS side and some kind of encoding/serialization, similarly to what you do in IPC/RPC. EDIT: I also suspect it's possible to exclude/disable val.h with a define flag (I didn't check this though).
[1] https://emscripten.org/docs/api_reference/bind.h.html#_CPPv4...