3 ms·

This is interesting, particularly for implementing Intl in JS engines without the mega-heavy ICU. But I wonder how portable it really is. Sometimes I have to d

This is interesting, particularly for implementing Intl in JS engines without the mega-heavy ICU. But I wonder how portable it really is. Sometimes I have to dig very deep to find that what folks call "portable C" is actually POSIX-dependent. It doesn't appear to be the case after going through the code for a bit, so that's promising.

mananaysiempre 4y ago
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. Duktape does casemapping but no normalization). Still, Bellard’s in particular look like he had a small Unicode processing library lying around and just copied it into the tree, not like he was forced to write the absolute minimum to do a JS inteprerer, so they can even be compared with dedicated libraries like libgrapheme, libutf8proc or libutf. [1] https://github.com/bellard/quickjs/blob/master/libunicode.c https://github.com/bellard/quickjs/blob/master/libunicode.c [2] https://github.com/svaarala/duktape/blob/master/src-input/duk_unicode.h https://github.com/svaarala/duktape/blob/master/src-input/du...
dochtman 4y ago
Maybe a comparison to ICU4X is more interesting.
layer8 4y ago
The functionality they’re implementing is purely string/byte processing, I don’t see what should introduce use of non-POSIX features.
dmitriid 4y ago
> 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.
- hnfong 4y ago
  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?

mananaysiempre 4y ago

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. Duktape does casemapping but no normalization). Still, Bellard’s in particular look like he had a small Unicode processing library lying around and just copied it into the tree, not like he was forced to write the absolute minimum to do a JS inteprerer, so they can even be compared with dedicated libraries like libgrapheme, libutf8proc or libutf. [1] https://github.com/bellard/quickjs/blob/master/libunicode.c https://github.com/bellard/quickjs/blob/master/libunicode.c [2] https://github.com/svaarala/duktape/blob/master/src-input/duk_unicode.h https://github.com/svaarala/duktape/blob/master/src-input/du...

dochtman 4y ago

Maybe a comparison to ICU4X is more interesting.

layer8 4y ago

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

dmitriid 4y ago

> 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.

hnfong 4y ago
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?