RFC: The encoding for type bytes

#1

Hi all,
We are evaluating that if it is worth to change the current encoding of bytes from regular js array to UInt8Array

Pros

  • Better performance
  • Better interop with Node API since Buffer is also UInt8Array

Cons

  • This is a ES6 feature, which means lacking support on IE

Thoughts?

#2

i think it is good, more performance. i don’t thing people still use IE these day :joy:

#3

Some still do, the question is whether the companies that support IE are advanced enough to use React :grin: IE is mostly irreplaceable in companies with legacy intranet projects, and it makes very little sense to write a legacy project in Reason :slight_smile:

#4

Add to the list less memory - currently we use 32 bit ints for each value rather than 8 bit ints.

I’d be very happy to see this change - and would be more likely to use BS in cases where I needed to read/write binary data

#5

I think we should be fine, because there are polyfills available.

e.g. https://github.com/substack/typedarray

#6

I remember @bloodyowl still supports IE10, is polyfill an option?

#7

IIRC I “cleaned” some code so that it wouldn’t import the bytes related modules. Would the polyfill be required for all cases (e.g. if pervasives had a side effect making use of them) or simply when making use of them?

#8

what is going to happen to the unsafe conversion functions between bytes and string?

#9

Can you be more specific?
Bytes.unsafe_{to,of}_string should be good

#10

I think it’s great. I think supporting more of es6 would be great in general. Most projects that need to support IE probably already have polyfills or another compile step in place.

#11

I’m all for this, as discussed on github some weeks ago. I haven’t had a chance to look into doing a PR myself since then, and to be honest I probably won’t have time until later this year.