Investigate experience from BigDecimal use in the JS ecosystem

[littledan]

As the README explains, various decimal libraries are already in wide use in the JS ecosystem. We should learn from the experience we already have what does and doesn't work, and make sure it's reflected in the design of BigDecimal.

[jakobkummerow]

I would suggest that the learnable experience is that this works just fine as a library. No need to add yet another feature to the language just for a few niche use cases. (Those use cases may well be valid, I'm certainly not saying they're not, but considering that they are not common, they are well-served by a library that only those clients/sites need to load that use it; whereas a feature added to the language bloats the platform for everyone, or creates fragmentation if some environments simply won't implement it -- which is yet another problem that user-space libraries don't have.)

[littledan]

@jakobkummerow That's definitely an important hypothesis to look into. Circumstantially, I've heard feedback on Twitter that the library is not quite enough: Lots of people who you'd think would benefit from the library seem to think that we'd benefit from something built-in. Some possible advantages of a language feature over an external library:

• Smaller download size, if this is bundled into lots of programs
• An easy choice when faced with the problem of what to use, reducing friction (vs needing to choose which decimal library, or to build an ad-hoc solution as many have mentioned doing)
• Potentially more integrated across the ecosystem and across standards
• Better ergonomics, reducing the risk that programmers will fall back on buggy solutions
• Avoids the need to trust the library maintainer (where, empirically, some people are up for trusting them, and others are not)

Can we find an agreeable way to research the importance of these issues, even if we have different personal feelings about them?

[jakobkummerow]

Wouldn't all five of those points be addressed by having a standardized (or otherwise somehow "officially blessed") library?

Besides, a particular counter-point on the first point: the download size wouldn't go away, it would just happen at a different time, specifically all users would have to download it every time they update their browser. Even users on low-end phones with limited-bandwidth connections.

[littledan]

Wouldn't all five of those points be addressed by having a standardized (or otherwise somehow "officially blessed") library?

The main differences between adding BigDecimal as a standard, built-in library and this proposal are:

• Ergonomics from operator overloading: Operator overloading is not currently supported in JavaScript, though I plan to propose it for Stage 1 in the December meeting. When we were considering BigInt, @BrendanEich argued convincingly that operator overloading for BigInt was essential for it to be useful for people.
• Value semantics: There are no current facilities in JavaScript for defining value types. These might be proposed in the future. Such value types would be useful to get the equality semantics that programmers may expect from BigDecimal.

If it's an officially blessed library that's not built-in to browsers, we'd further lose the benefits of download size reduction and possible integration into other things that are built-in to browsers. We'd also lose structured clone semantics, unless some facility for user-defined structured clone is created.

Besides, a particular counter-point on the first point: the download size wouldn't go away, it would just happen at a different time, specifically all users would have to download it every time they update their browser. Even users on low-end phones with limited-bandwidth connections.

I think browser updates happen less frequently than cold page loads (assuming some percentage of those actually want to use BigDecimal), so if the increase in size isn't prohibitively large, this seems like a reasonable tradeoff to make. Very large increases in browser size would be a good reason to look back at this proposal to see if it's really feasible--we made changes Unified Intl.NumberFormat Options to ensure we weren't requiring shipping impractically much data with browser updates, even though the problem was only noticed in Stage 3 (cc @sffc).

[sffc]

The download size argument is hard to apply for BigDecimal. I imagine that the code is small whether it is a third-party library or whether it is built into the browser. Data size is more of a concern for ECMA-402 proposals because we have to carry not only code, but also locale data, sometimes for hundreds of locales at a time.

By the way, an advantage of BigDecimal from an Intl point of view is that we could format BigDecimal arguments in Intl.NumberFormat. We wouldn't be able to do that if BigDecimal were restricted to a third-party library.