> I do not think a suggestion to "encourage UTF-8 for new formats and APIs" can be said to "literally breaking the Web Platform"
Perhaps you don’t see it that way, but we have to respect when others do.
From the way I understand things, because JS strings (DOMString [1]) are already represented as UTF-16/WTF-16 internally, making the component model strings only UTF-8 puts certain languages in disadvantage against others specially regarding speed (because they’ll need to do extra effort when processing strings in order to be fully compliant, while the UTF-8 ones wouldn’t need to do it). This was the case for AssemblyScript, Javascript, Java and other JVM-related languages (Kotlin, Scala, ...).
Specifically for a language such as AssemblyScript, for which its aim is to be completely complaint with JS, tiny and fast to execute I can certainly understand why that was a concern and why being dismissed could cause certain frustration.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Perhaps you don’t see it that way, but we have to respect when others do.
From the way I understand things, because JS strings (DOMString [1]) are already represented as UTF-16/WTF-16 internally, making the component model strings only UTF-8 puts certain languages in disadvantage against others specially regarding speed (because they’ll need to do extra effort when processing strings in order to be fully compliant, while the UTF-8 ones wouldn’t need to do it). This was the case for AssemblyScript, Javascript, Java and other JVM-related languages (Kotlin, Scala, ...).
Specifically for a language such as AssemblyScript, for which its aim is to be completely complaint with JS, tiny and fast to execute I can certainly understand why that was a concern and why being dismissed could cause certain frustration.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...