←back to thread

239 points ivankra | 1 comments | | HN request time: 0s | 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 #
ambicapter ◴[] No.45946210[source]
Unicode is everywhere though. You'd think there'd be much greater availability of those tables and data and that people wouldn't need to bundle it in their executables.
replies(1): >>45946487 #
nicoburns ◴[] No.45946487[source]
Unfortunately operating systems don't make the raw unicode data available (they only offer APIs to query it in various ways). Until they do we all have to ship it seperately.
replies(2): >>45949837 #>>45951294 #
1. lifthrasiir ◴[] No.45951294{3}[source]
For some OSes like Windows, some relevant APIs can be indeed used to reconstruct those tables. I found that this is in fact viable for character encoding tables, only requiring a small table for fixes in most cases.