Looks very cool, although I wish they used more Excel-like number formats (http://office.microsoft.com/en-us/excel-help/number-format-c...)

Shameless plug: as part of the in-browser XLS parsing, we built a library for formatting numbers: https://github.com/SheetJS/ssf

How do I do Indian-style comma formatting with Numeral.js? Like so: 10,00,00,000, with thousands grouped in three digits and everything else in two digits.

I in no way mean for this to be disrespectful, but boy that looks confusing to my Western brain.

Japanese numbers used to be delimited with commas every four digits, like so: 1,0000,0000 due to the largest common single-use (i.e., not a combination of a small number plus a large number as in "hundred thousand") being 10,000 (万, man).

Nowadays I've only ever seen US-style commas and it's hard to even find a reference to the four-digit commas online.

Exactly what I was also thinking.

Thanks for sharing! Unfortunately, bytes representations are wrong.

As you may now, there is a difference between kilobytes (KB) and kibibytes (KiB), megabytes (MB) and mibibytes (MiB) et cetera. 1 KiB = 1024 bytes = 1.024 KB.

Please check out https://en.wikipedia.org/wiki/Binary_prefix and fix your library :)

That convention is not universally recognized.

...or barely recognised at all?

Looks like it does a subset of what the native Window.Intl does, a shame so few developers know about window.Intl...

Still, nice effort! I like it

Thanks, I learned something new! But yeah, as other people have pointed out, browser support starts with IE 11 and almost no mobile browser supports it - so it might as well not exist.

Intl is rather excellent, and if you do want to use it there's an nice shim for it here: https://github.com/andyearnshaw/Intl.js

I've been using this with great results so far. It works well with a loader (e.g. yepnope) as Chrome and Firefox support it natively, as does IE11.

Thanks for the shim, I was looking for that - very useful and passes all my tests in IE10.

That's probably because most developers care about compatibility.

Surely, you mean, most developers only care about compatibility with Chrome ?

You raise an interesting point: if we were the only ones in charge I'd say that a sizable proportion of us, developers, would target Chrome and only Chrome. But we unfortunately have to deal with functional specs and project managers and "clients" (whatever that is) and older browsers that force us to think in compatibility terms rather than coolness terms.

I work for a company where we still have customers using IE 7, so I know what you mean.

But no, I don't want to develop only for Chrome, and these days, you see a lot of that happening on "cool tech", even when there is the equivalent in, at least, Firefox.

With shimmable APIs?

I didn't know about that until now. Here's a neat blog post on the subject - http://marcoscaceres.github.io/jsi18n/

That said, numeral.js doesn't look like just subset, it's got a nice interface to work with, and you don't have to worry about cross-browser inconsistency. You just have to believe this library does everything correctly for each language/locale.

A jQuery plugin that does formatting in a more jQuery-like manner can be found here - https://code.google.com/p/jquery-numberformatter/

It aims to mimic how number formatting is done on the server.

You know, I was looking at this and thinking "you know, this needs to be more jQuery-er!"

Another similar library: http://josscrowcroft.github.io/accounting.js/

Used on many projects, works well.

> 10000 '0,0.0000' 10,000.0000

Because you know, why implement UTS #35? It exists and covers dozens of cultural contexts and that's no fun.

UTS #35 is Unicode Technical Standard #35, Unicode Locale Data Markup Language (LDML), http://www.unicode.org/reports/tr35/.

Yep, more specifically (for this situation) numbers and currencies formatting (and format patterns)[0] and the related data in the CLDR (the LDML defines the CLDR's structures, the CLDR itself holds locale data such as the actual patterns and specific translated terms)

[0] http://www.unicode.org/reports/tr35/tr35-numbers.html

> c.add(10).value();

No, numbers aren't (shouldn't be) treated as objects.

Handy. Thanks!