However, when posting a new package it is most useful to discuss it in comparison to established packages. Specifically, what are the pros/cons of this package compared to numericjs [1] and jstat [2]?
Also, in general, I think it is a mistake to mix plotting and numerics in a single package. These are two quite different things and are probably better served by more focused packages.
There is some overlap between those libraries. However, it does one thing that none of the other JS libraries (from here: http://jster.net/category/math-libraries) really focus on: to support the full complex domain for all the functions.
About numerics vs plotting: They are in different js files, jsmat.js and jsmat_plot.js. The plotting file depends on the numerics one though, as it needs to use its Complex type. The main focus of the package is the numerics, the plotting is a demo, and especially, debugging device.
The Bessel function(s) are pretty difficult to calculate and generally have to be calculated numerically via any of several methods. Looking at the numbers you posted, I'd say that Jmat is probably using a different algorithm and/or precision level than the others. My hunch would be that it's using a series expansion, while the other software is using one of the more clever algorithms.
PS: In Mathematica, you should probably use "N[..., 20]" instead of "SetPrecision". It not quite the same and using SetPrecision can cause odd effects if you're not careful, like accidentally triggering numerical evaluation too early.
It looks like Jmat is using the series expansion (about zero) for Re(z)^2 < (Re(n)+1)/10, with z the argument and n the order. They switch to the asymptotic form for larger arguments, but they're only using the first term.
To improve accuracy, they could truncate the large order expansion when the terms start growing or drop below precision. See the wonderful DLMF S10.17 (http://dlmf.nist.gov/10.17) for the higher order terms.
Note that this expansion will not perform well for large order, and they should switch to one of the series in order instead. Olver's uniform expansion is lovely, but a bit tedious to implement.
You do realize that static typing has nothing to do with code size (where did you get that bizarro idea from?).
Emscripten transpiled code is a bloated of redundancy in order to cover C constructs in Javascript code, for things that can be done shorter in idiomatic javascript. But you don't have to take my word for it. Check emscripten transpiled stuff that's out there and their sizes (even compared to the equivalent executable binaries for the same code).
Faster it might be (if it uses asm.js style tricks), but have you profiled to ensure that speed is lacking on that particular codebase we're talking about? Or that you can't just have a minimal asm.js/emscripten style base core and do the higher level stuff in pure high level js?
You make the claim that pure JS would be smaller than Emscripten compiled JS because of having to support C constructs in an awkward manner. This might be somewhat true in regard to pointers but not enough to make a difference. Please show some example codes
However, when posting a new package it is most useful to discuss it in comparison to established packages. Specifically, what are the pros/cons of this package compared to numericjs [1] and jstat [2]?
Also, in general, I think it is a mistake to mix plotting and numerics in a single package. These are two quite different things and are probably better served by more focused packages.
[1] http://www.numericjs.com/ [2] https://github.com/jstat/jstat