You can also refer to the Unicode routines of other small JS engines[1,2], those don’t use ICU either, although the implementations are mercilessly size-optimized (to put it politely) and restricted to what the target JS version requires (e.g. casemapping but no normalization).

[1] https://github.com/bellard/quickjs/blob/master/libunicode.c

[2] https://github.com/svaarala/duktape/blob/master/src-input/du...

Maybe a comparison to ICU4X is more interesting.

The functionality they’re implementing is purely string/byte processing, I don’t see what should introduce use of non-POSIX features.

> This is interesting, particularly for implementing Intl in JS engines without the mega-heavy ICU.

On the contrary, every single programming language and platform should by default include ICU and provide easy bindings to its functionality. Because even normalization and equality comparisons are often done poorly or not at all in these "simple" libraries.

To the contrary I think ICU should be better handled as a "third party" library.

It gets updated quite often, and changes between versions can be substantial. If the developer cares about correctness, they need to have explicit control over the actual version of ICU they're bundling, instead of having the language/platform dealing with it as a black box.

It can be argued that in such cases they can always bundle their own custom version, but then the argument boils down to whether it's better to assure the developer that it works automagically even though it's only correct 99% of the time, or whether to not provide a default implementation and risk them choosing to implement a poor one themselves?