Wasm could have had a concept of a string. I frequently mourn the rejection of the imo excellent stringref proposal. https://github.com/WebAssembly/stringref
wasm 3 has the JavaScript string built-in now according to TFA
That's a different thing. There is still no string type. JS string built-ins are a kludge for web targets only.
Just reimplement those JS string builtins in another host environment and provide it as a Wasm library. Stringref was basically just proposing pushing JS strings down into Wasm, which many in the CG saw as a big chunk of one specific platform just moving down a layer, into the engine.
Having used and implemented stringref and having seen the built-ins proposal I really think stringref is a much better developer experience and the CG is wrong. The built-ins are better than nothing but it's a terrible hack.
Re:WASM 3.0 Completed
by dcchambers on Wednesday September 17, 2025 @04:12PM
(#45280814)
Fair enough, thanks for sharing!
https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
The only thing that might be expensive is translating string data from the language-specific string representation on the WASM heap into the JS string objects expected by the DOM API. But this same problem would need to be solved in a language-portable way for any native WASM-DOM-API, because WASM has no concept of a 'string' and languages have different opinions about what a string looks like in memory.
But even then, the DOM is an inherently slow API starting with the string-heavy API design, the bit of overhead in the JS shim won't suddenly turn the DOM into a lightweight and fast rendering system.
E.g. it's a bit absurd to talk about performance and the DOM in the same sentence IMHO ;)