The idea of Wasm as a universal plugin system is very promising. But string passing is maybe not the best example to highlight, considering that Wasm is introducing stringref to enable zero-copy string sharing between the Wasm runtime and host language.
I'm working on a WASM project[0] with Andy, the stringref champion, and unfortunately the future for stringref is uncertain. There is now a new proposed alternative called "JS string builtins"[1]. The way we intend to ship support for strings currently is to just use JS string builtins, because it is just a set of imported functions, not new instructions. Those imports can either be provided by efficient, native compiled functions (currently behind a V8 feature flag, not sure if other JS engines support it) or from a JS polyfill. It's not an ideal situation but this will allow for shipping strings that work in all browsers with default settings.
While it'd be a nice addition, I wouldn't expect it any time soon.
It's currently still a stage 1 proposal, while we've been waiting for years for other proposals to be merged. The last time a proposal was actually finished was over 2 years ago.
For your second one, it looks like it is already implemented in Chromium and Firefox but not Safari. Sadly, it's not new for Apple to be dragging their feet on moving web standards forward.
It took what seems like a decade to get proper WebRTC support in Safari.
> WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
I was going to say that everything around interoperability in Wasm has been stalled for years, but hey, looks like garbage collection has reached phase 4! That's a pretty big one!
The component model (aka interface types aka snowman types aka...) is still stuck is phase 1, though. After almost four years, that's not encouraging.
This is the first time I saw a mention of WTF-8 [1] and WTF-16. From the spec description this seems strange to use this interoperability "hack" (using the word from the spec) as the foundation of the string proposal. I wonder if they could use UTF-8 instead and keep WTF-16 for interoperability with JavaScript.
> WTF-8 [...] is a superset of UTF-8 that encodes surrogate code points if they are not in a pair. It represents, in a way compatible with UTF-8, text from systems such as JavaScript and Windows that use UTF-16 internally but don’t enforce the well-formedness invariant that surrogates must be paired. WTF-8 is a hack intended to be used internally in self-contained systems with components that need to support potentially ill-formed UTF-16 for legacy reasons.
https://github.com/WebAssembly/stringref/blob/main/proposals...