5 ms·

I am skeptical of WebAssembly and component-model myself, but that AssemblyScript page seems alarmist and as can be seen in several issues linked from that page

I am skeptical of WebAssembly and component-model myself, but that AssemblyScript page seems alarmist and as can be seen in several issues linked from that page, dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith: https://github.com/w3ctag/design-principles/issues/322 https://github.com/w3ctag/design-principles/issues/322 It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web", which seems patently absurd, but also, just plain boring. I was definitely expecting more along the lines of incompatible object models integrating into component‐model, rather than mass-tagging people over string encodings.

zozbot234 4y ago
> It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web" And by "against the practices of the web" they really mean against the practices of Java/JavaScript. But I thought that was the whole point of WASM?
syrusakbary 4y ago
> dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith I certainly disagree with that take. I don’t see any bad faith, I only see one person being frustrated because his concerns were being thrown under the rug as "non important", I would recommend you to read on dcode's blog to learn more about it [1]. There are always things to improve regarding how we communicate, of course, but those should not be used as a weapon to attack or dismiss someone but as means to improve. It's also important to note that a few months after, the Wasm committee realized of the mistake and actually tried to solve it with the Wasm Stringref proposal [2]. The way I see the issue is not about UTF-8 vs UTF-16 but about how valid concerns were completely dismissed in what's supposed to be an open community [1] https://dcode.io/#webassembly https://dcode.io/#webassembly [2] https://github.com/WebAssembly/stringref https://github.com/WebAssembly/stringref
- Jasper_ 4y ago
  There are valid concerns to be had about string encodings, but I do not think a suggestion to "encourage UTF-8 for new formats and APIs" can be said to "literally breaking the Web Platform", nor does it require tagging 17 people, most of them unrelated, just because you happen to disagree the resolution of the committee.
  - dcode 4y ago
    Perhaps this is missing some necessary context. Note that the threads happened before a resolution, and have been created a few days before using them as an argument in Wasm. There was and still is no such design principle, because it doesn't make sense. Similarly, the arguments in the thread referenced are nonsense. JSON and CSS modules are files, which have different requirements than API calls. importScript the same, loads source code. Also note that JSON actually preserves idiomatic JS strings in data (APIs) through escape sequences, even though it stores as UTF-8 (files). Preserving in JSON makes sense, since sometimes JSON.stringify/parse are used for things like synchronous IPC, where maintaining integrity is critical. The Component Model should do the same, but refuses. The others are networking APIs, where UTF-8 is common. These are asynchronous and typically untrusted, where the protocols mandate UTF-8, and not maintaining synchronous state is much less problematic there. However, mutating string data as a side-effect of a normal function call is nothing less than a hazard, since some strings then seemingly randomly won't compare equal anymore after a call and stuff like that. WTF-16 (what JS effectively specifies) -> UTF-8 is lossy. The people in the threads know that very well, but keep bringing up the same already debunked arguments over and over again nonetheless to get their way. There, the thread suggests to encourage UTF-8 for new JavaScript APIs as well, which plays into the desires on the Wasm end yet is well-known to be impossible to pull off in JS. Applying this to JS conflicts with the ECMAScript specification, because JS has the same hard backward-compatibility constraints as Java, Dart, Kotlin, C# and other languages that evolved from UCS-2 to WTF-16. None of these languages can change their string semantics, in particular not to something akin to UTF-8, since it's semantically more restrictive and hence would break execution of existing and, arguably, all future code using idiomatic APIs like substring without being aware of potential mutation. It's subtle, I admit, but given that the arguments are factually invalid, the threads can only be one of two things: Incompetence or dishonesty. As always in political contexts, the mere mortal wonders what's better. Given foregoing discussions, where the same people participated, I would rule out incompetence. Now go there and question, and always the same gate keepers show up, simulating responses in good faith. Killing you with kindness, or however that's called. Dare to be unimpressed and follow-up, and someone quick-draws a CoC. That's why I decided to try something new, there pinging various people from the TAG, in the hope to finally get eyes on this behavior by someone knowledgeable, which obviously failed as well. Not sure if that helps, but that's some of the background :) FWIW, here's the presentation I wanted to give to the Wasm CG that explains the details and pitfalls in an easier to digest way: https://www.youtube.com/watch?v=Ri2NMnSQo4o https://www.youtube.com/watch?v=Ri2NMnSQo4o

zozbot234 4y ago

> It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web" And by "against the practices of the web" they really mean against the practices of Java/JavaScript. But I thought that was the whole point of WASM?

syrusakbary 4y ago

> dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith I certainly disagree with that take. I don’t see any bad faith, I only see one person being frustrated because his concerns were being thrown under the rug as "non important", I would recommend you to read on dcode's blog to learn more about it [1]. There are always things to improve regarding how we communicate, of course, but those should not be used as a weapon to attack or dismiss someone but as means to improve. It's also important to note that a few months after, the Wasm committee realized of the mistake and actually tried to solve it with the Wasm Stringref proposal [2]. The way I see the issue is not about UTF-8 vs UTF-16 but about how valid concerns were completely dismissed in what's supposed to be an open community [1] https://dcode.io/#webassembly https://dcode.io/#webassembly [2] https://github.com/WebAssembly/stringref https://github.com/WebAssembly/stringref

Jasper_ 4y ago
There are valid concerns to be had about string encodings, but I do not think a suggestion to "encourage UTF-8 for new formats and APIs" can be said to "literally breaking the Web Platform", nor does it require tagging 17 people, most of them unrelated, just because you happen to disagree the resolution of the committee.
- dcode 4y ago
  Perhaps this is missing some necessary context. Note that the threads happened before a resolution, and have been created a few days before using them as an argument in Wasm. There was and still is no such design principle, because it doesn't make sense. Similarly, the arguments in the thread referenced are nonsense. JSON and CSS modules are files, which have different requirements than API calls. importScript the same, loads source code. Also note that JSON actually preserves idiomatic JS strings in data (APIs) through escape sequences, even though it stores as UTF-8 (files). Preserving in JSON makes sense, since sometimes JSON.stringify/parse are used for things like synchronous IPC, where maintaining integrity is critical. The Component Model should do the same, but refuses. The others are networking APIs, where UTF-8 is common. These are asynchronous and typically untrusted, where the protocols mandate UTF-8, and not maintaining synchronous state is much less problematic there. However, mutating string data as a side-effect of a normal function call is nothing less than a hazard, since some strings then seemingly randomly won't compare equal anymore after a call and stuff like that. WTF-16 (what JS effectively specifies) -> UTF-8 is lossy. The people in the threads know that very well, but keep bringing up the same already debunked arguments over and over again nonetheless to get their way. There, the thread suggests to encourage UTF-8 for new JavaScript APIs as well, which plays into the desires on the Wasm end yet is well-known to be impossible to pull off in JS. Applying this to JS conflicts with the ECMAScript specification, because JS has the same hard backward-compatibility constraints as Java, Dart, Kotlin, C# and other languages that evolved from UCS-2 to WTF-16. None of these languages can change their string semantics, in particular not to something akin to UTF-8, since it's semantically more restrictive and hence would break execution of existing and, arguably, all future code using idiomatic APIs like substring without being aware of potential mutation. It's subtle, I admit, but given that the arguments are factually invalid, the threads can only be one of two things: Incompetence or dishonesty. As always in political contexts, the mere mortal wonders what's better. Given foregoing discussions, where the same people participated, I would rule out incompetence. Now go there and question, and always the same gate keepers show up, simulating responses in good faith. Killing you with kindness, or however that's called. Dare to be unimpressed and follow-up, and someone quick-draws a CoC. That's why I decided to try something new, there pinging various people from the TAG, in the hope to finally get eyes on this behavior by someone knowledgeable, which obviously failed as well. Not sure if that helps, but that's some of the background :) FWIW, here's the presentation I wanted to give to the Wasm CG that explains the details and pitfalls in an easier to digest way: https://www.youtube.com/watch?v=Ri2NMnSQo4o https://www.youtube.com/watch?v=Ri2NMnSQo4o