I don’t think there’s a straightforward answer to that (or rather, the answer is: it depends).
Belt.Array functions are mostly thin wrappers on top of native JS functions. If you’re concerned about compiled JS code size, Belt.Array is fairly small, but it relies on other BuckleScript modules for features like currying.
Js.Array, by contrast, is just a binding to the existing JS API. It compiles to pure JS array methods with no dependencies or additional runtime cost.
From reading that, it probably sounds like Js.Array is superior. But there are other factors to consider. For example: If your project is nontrivial, then you’re probably using the same BuckleScript modules that Belt.Array relies on anyway. Belt.Array also has functions that aren’t in Js.Array. Js.Array lacks the ability to “safely” get a value, which gives up one of the main benefits of using Reason the first place.
(Reason code like
arr does not compile to JS
arr. It compiles to an OCaml function that will throw an exception if the item doesn’t exist. See more examples here.)
Belt.Array largely exists to provide an API that’s consistent with the rest of Belt. If you’re using other Belt modules, then it will fit in much easier with the rest of your code.
As with everything performance related, what’s best for your project will depend on a lot of factors. It’s possible that you may be better off using a different data type, like a list (or even a map or a hashmap).
Finally, here’s some anecdotal bundle size data: In my personal project that uses ReasonReact, Belt.Array is 2.42KB (0.6% total bundle size), and bs-platform is 35.37KB (8.5% total bundle size).
For me, the bundle size and runtime cost is so small that choosing one API or the other is just a matter of personal taste.