4 ms·

> For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? This doesn't really ex

> For a new language targeting WASM, it might be nice to use JavaScript strings directly, without needing to convert them at the border? This doesn't really exist unless you mean they need to not operate on the strings in their own memory and instead make a bunch of JS calls to operate on strings. That has overhead. Otherwise you have to use some approach to get the string to an array buffer (e.g. TextEncoder, charCodeAt, etc) and even though they are probably utf-8 internally, the step still exists to get them to WASM memory. For the GP's post about combining languages, it's no fun to do all of this to use a WASM Rust string in WASM Go (this is what I meant about "lowest common denominator").

derefr 9y ago
> That has overhead. Yeah, but if those strings are destined for, say, the DOM, in such a way where you're going to constantly mutate little bits of the string while it's in the DOM, then it's probably less overhead to keep the string as a foreign object handle that you can send commands to from WASM to modify the string in place in JS VM memory, than it is to keep the string in the WASM memory buffer and "blit" it to JavaScript land whenever you change it. (Consider: how would you implement something like the Atom editor in WASM with as little additional overhead as possible?) Also, maybe this overhead can be reduced. Picture an enhanced ArrayBuffer type specifically for WASM to use, that acts like virtual memory, with an MMU API attached to map Javascript objects into it—facilitating a kind of DMA. Or, allowing you to define "IO ports" in the memory space that WASM can write to to generate Nagle-chunked message events for JS-land, and which will appear to JS-land as a Javascript Service Worker endpoint that can be addressed with messages that will be turned into a buffered stream of bytes WASM can pull out of the same IO port.

derefr 9y ago

> That has overhead. Yeah, but if those strings are destined for, say, the DOM, in such a way where you're going to constantly mutate little bits of the string while it's in the DOM, then it's probably less overhead to keep the string as a foreign object handle that you can send commands to from WASM to modify the string in place in JS VM memory, than it is to keep the string in the WASM memory buffer and "blit" it to JavaScript land whenever you change it. (Consider: how would you implement something like the Atom editor in WASM with as little additional overhead as possible?) Also, maybe this overhead can be reduced. Picture an enhanced ArrayBuffer type specifically for WASM to use, that acts like virtual memory, with an MMU API attached to map Javascript objects into it—facilitating a kind of DMA. Or, allowing you to define "IO ports" in the memory space that WASM can write to to generate Nagle-chunked message events for JS-land, and which will appear to JS-land as a Javascript Service Worker endpoint that can be addressed with messages that will be turned into a buffered stream of bytes WASM can pull out of the same IO port.