Intl.NumberFormat
It knows about currencies, locales, units and compact notation, and it is faster than the string concatenation it replaces.
I still find this in checkout code constantly:
'$' + (cents / 100).toFixed(2)
which is fine until the store sells to somebody who writes 1.234,56, or until the currency is one of the ones with no minor unit, or until a total needs to be US$ rather than $ because the page also shows Canadian dollars. Many such cases.
new Intl.NumberFormat('en-US', {
style: 'currency',
currency: 'USD',
}).format(1234.5);
// "$1,234.50"
Swap the locale and the separators, the symbol position and the spacing all change without you knowing any of the rules. It knows that Japanese yen has no decimal places and Kuwaiti dinar has three.
Two other things it does that I reach for:
new Intl.NumberFormat('en', { notation: 'compact' }).format(48291);
// "48K"
new Intl.NumberFormat('en', { style: 'unit', unit: 'megabyte' }).format(4.2);
// "4.2 MB"
The one performance note worth having: constructing the formatter is the expensive part, not calling it. If you are formatting a table of 500 prices, build one formatter outside the loop. Done that way it is comfortably faster than the string work it replaces, which is not the direction anybody expects.
Intl.RelativeTimeFormat and Intl.PluralRules are in the same family and solve the two other problems everybody hand-rolls.