3 ms·

This means that handling of modern cases (e.g., characters taking up more than one byte) happens naturally, efficiently, and hopefully more bug-free. This isn'

• saurik 13y ago
  JavaScript doesn't even handle "characters taking up more than one byte" once you abstract to "more than one X" (or, alternatively, "more than two bytes"): JavaScript strings are really binary 16-bit numeric arrays, which frankly is even worse than using 8-bit numeric arrays as developers are much more likely to throw up their hands and claim "those characters don't happen often enough for me to dirty up my beautiful code" (the response I seriously got when I started working on patches to support UTF-16 for ACE; it was really annoying and horribly disappointing: they seemed to believe they could just ignore the problem in general and solve it at the edges, which is a total misunderstanding of the scope of the issue). In essence, JavaScript's string is no better than C++11's std::u16string, and in fact is even worse as the language doesn't provide anything similar to std::codecvt, so you are stuck implementing UTF-16 conversions yourself in a language that doesn't even have an integral data type :(. (Incidentally, Java's String also sucks at this, so it isn't like the "native applications" side of this argument is doing so well, with C++ and Java both down for the count; only Objective-C has a real Unicode-compliant NSString class.)