←back to thread

239 points ivankra | 2 comments | | HN request time: 0.444s | source
Show context
bcardarella ◴[] No.45945551[source]
Just a small comparison, compiled for release:

Boa: 23M Brimstone: 6.3M

I don't know if closing the gap on features with Boa and hardening for production use will also bloat the compilation size. Regardless, for passing 97% of the spec at this size is pretty impressive.

replies(3): >>45945705 #>>45945748 #>>45950091 #
jerf ◴[] No.45945748[source]
It looks like Boa has Unicode tables compiled inside of itself: https://github.com/boa-dev/boa/tree/main/core/icu_provider

Brimstone does not appear to.

That covers the vast bulk of the difference. The ICU data is about 10.7MB in the source (boa/core/icu_provider) and may grow or shrink by some amount in the compiling.

I'm not saying it's all the difference, just the bulk.

There's a few reasons why svelte little executables with small library backings aren't possible anymore, and it isn't just ambient undefined "bloat". Unicode is a big one. Correct handling of unicode involves megabytes of tables and data that have to live somewhere, whether it's a linked library, compiled in, tables on disks, whatever. If a program touches text and it needs to handle it correctly rather than just passing it through, there's a minimum size for that now.

replies(6): >>45945844 #>>45945976 #>>45946210 #>>45947165 #>>45947379 #>>45951653 #
1. jancsika ◴[] No.45947165[source]
If someone builds, say, a Korean website and needs sort(), does the ICU monolith handle 100% of the common cases?

(Or substitute for Korean the language that has the largest amount of "stuff" in the ICU monolith.)

replies(1): >>45947451 #
2. adzm ◴[] No.45947451[source]
Yes, though it's easy to not use the ICU library properly or run into issues wrt normalization etc