Math. Js: An Advanced Mathematics Library For JavaScript

Operation Library 
math.js Sylvester numeric.js ndarray numpy 
(Python) 
Octave 
(C++) 
A+A 
9 9 2 3 53 3 
A*A 236 182 25 44 75 11 
A’ 4 8 2 2 29 2 
det(A) 10,374 
205 3 
3 
94 21 
The results reveal a number of interesting observations. First, Octave performs best, together 
with the two fastest JavaScript libraries, numeric.js and ndarray. This is surprising because 
scripting languages are typically slower than compiled languages. Math.js performed slowest of 
all of the JavaScript libraries, and has one sore spot: calculation of the determinant severely un-
derperforms the other libraries. Python performs an order of magnitude slower than Octave and 
the fastest JavaScript libraries. 
At first, these results might appear to be bad news for math.js. However, the fact that numeric.js 
and ndarray perform about as good as Octave suggests that with effort, math.js might also reach 
that level of performance. 
CHALLENGES 
Current math.js challenges include issues of performance, library size, and standards, as detailed 
below. 
Performance
So far, performance hasn’t been a primary concern for math.js. The most important goal was to 
create an integrated environment to work with data types and functions. Now that math.js is ma-
turing, performance is becoming more important. JavaScript and math.js are probably not the 
best choice for heavy-duty computational tasks such as numerical simulations or optimization 
algorithms. After all, many real-world applications don’t have high demands. They might plot 
29
January/February 2018
www.computer.org/cise

---

THE RISE OF JAVASCRIPT 
some graphs, convert units, do some matrix calculations, and so on. For these purposes, the per-
formance of math.js is adequate.
Matrix calculations are typically the most computationally demanding, so these algorithms need 
to be implemented in an efficient way. One improvement that can be made to math.js is the use 
of typed arrays, a relatively new JavaScript feature. But no matter how many improvements are 
made, math.js will always be bound by the performance limitations of JavaScript. Performance 
of JavaScript engines has been rapidly improving, but its performance is still worse than low 
level languages like C/C++, and this might always be the case. 
Library Size 
The size of JavaScript libraries is a big issue in web applications because every time a web appli-
cation is opened, it might have to download and load the entire codebase before rendering the 
page. A large library size can have a huge impact on page load times, which is a detriment to the 
user experience. The effect is even stronger on mobile devices with slower connection speeds 
and less powerful hardware. A common rule of thumb is that a web page should deliver content 
within 1 second.
31
At the moment, the size of the math.js library is about 127 kB when compressed. Downloading it 
takes some time depending on a device’s Internet speed, and loading it takes an additional 100 
milliseconds or more. These numbers might sound small, but they are large in the web develop-
ment world. The current average amount of JavaScript on web pages is 446 kB,
32
and adding 
math.js to a website has a serious impact. In many cases, applications only use a small part of 
math.js, like the expression parser for basic arithmetic with numbers. Being able to exclude un-
used parts of math.js from an application bundle would improve load time. 
Tree shaking is a common optimization technique in JavaScript that detects and removes unused 
code. Ideally, this would solve the problem for applications using only a small part of math.js. 
Unfortunately, this is not currently possible in its entirety: math.js contains 10 different data 
types and more than 170 functions, with each function containing an implementation for each 
data type (where applicable). It’s relatively straightforward to exclude functions from the bundle, 
but it’s not possible to exclude entire data types, such as Matrix. 
A first step made to address this issue would be to modularize the source code of math.js, and 
allow custom bundling.
33
This enables creating a math.js bundle containing only a subset of 
manually included files. There is still open discussion about creating an automated solution for 
this. 
Standards 
There are various standards for representing mathematics on the web: MathML, LaTeX, 
ASCIIMath, and others. Most of these standards have been developed for rendering math. 
Math.js has its own syntax similar to ASCIIMath, but it is intended for calculation rather than 
display. Math.js would become even more powerful if its syntax was compatible with one of 
these standards. This would boost interoperability because the same expression could be used for 
both calculation and rendering. It could even make printed math interactive or add visual repre-
sentations to math applications such as math.js. 
The best-known web standard for math is MathML. Unfortunately, this isn’t a viable option. The 
standard is verbose and extensive, creating a large barrier for applications to implement this 
standard. And there is a practical issue: MathML isn’t supported by all browsers, raising the 
question of whether MathML is still relevant for the web. 
Currently, math.js can export expression to LaTeX. This allows one to graphically represent an 
expression using a math rendering library such as MathJax.
34
The reverse operation—creating a 
30
January/February 2018
www.computer.org/cise

---

COMPUTING IN SCIENCE & ENGINEERING 
math.js expression from a LaTeX string—is not supported and would be much more complicated 
to implement. 
There is a need for a standard that is more simple and concise than existing industry standards 
like MathML and LaTeX. An initiative by the W3C working group “mathonwebpages”
35
is in-
vestigating options for a more approachable standard. Ideally, this standard would be easy to 
read and write by humans. However, it is a challenge to come up with a standard that is simple, 
accessible, versatile, open, and useable for both rendering and calculating math. 
DISCUSSION AND FUTURE WORK 
The math.js library is currently one of the best-known math libraries for JavaScript. This library 
allows both mathematicians and programmers to work with many data types in an integrated en-
vironment, and makes expressing mathematics easier by providing its own math-oriented syntax 
on top of a low-level JavaScript API. 
Although JavaScript is slower than low-level languages like C++, the gap isn’t that large any-
more and using JavaScript for mathematics can be a suitable solution for many real-world appli-
cations. An important reason to use JavaScript is that it can run anywhere: in the browser, on the 
server, or on a desktop. 
Now that math.js is maturing, performance is becoming a priority. It’s currently one of the slow-
est math libraries available, and there are many optimizations that can still be made. There is also 
need for improvements in its modularization and library size—important aspects for web appli-
cations. For instance, math.js can import new functions or exclude existing ones, but there is no 
provision to import new data types or exclude data types. Despite this, work is continuing to ex-
pand math.js’s built-in functions and algorithms and to solidify its support for algebra, which 
was added just recently. 
A different type of challenge is the support behind math.js and many other JavaScript math li-
braries. To stay healthy, these projects should attract more contributors. They might also benefit 
from sponsorship by companies or a foundation to ensure their continuation. Math.js is a young, 
promising math library in the vibrant and fast-growing JavaScript community. Hopefully it will 
serve many and make the web a better place for mathematics in the years to come. 
REFERENCES 
1.
D. Arno, “Why JavaScript is a Toy Language,” 2010; 
www.davidarno.org/2010/05/18/why-javascript-is-a-toy-language. 
2.
“Browser wars,” Wikipedia; 
en.wikipedia.org/wiki/Browser_wars#Second_Browser_War. 
3.
“Node.js,” Wikipedia; en.wikipedia.org/wiki/Node.js#History. 
4.
“Electron”; electron.atom.io. 
5.
P. Catanzariti, “JavaScript Beyond the Web,” SitePoint, 2013; 
www.sitepoint.com/javascript-beyond-web. 
6.
“CouchDB,” Apache Software Foundation, 2017; couchdb.apache.org. 
7.
“SciPy.org,” 2017; www.scipy.org. 
8.
“ndarray: Multidimensional Arrays for JavaScript” GitHub; github.com/scijs/ndarray. 
9.
“Sylvester: Vector and Matrix Math for JavaScript”; sylvester.jcoglan.com. 
10.
“Complex.js: A Complex Number Library,” GitHub; github.com/infusion/Complex.js. 
11.
“Numbers.js: Advanced Mathematics Library for Node.js and JavaScript,” GitHub; 
github.com/numbers/numbers.js. 
12.
“Numeric JavaScript”; www.numericjs.com. 
13.
“Algebrite: Computer Algebra System in JavaScript”; algebrite.org. 
31
January/February 2018
www.computer.org/cise

---

THE RISE OF JAVASCRIPT 
14.
“Algebra.js: Build, Display, and Solve Algebraic Equations,” GitHub; 
github.com/nicolewhite/algebra.js. 
15.
“Expr-eval: Mathematical Expression Evaluator in JavaScript,” GitHub; 
github.com/silentmatt/expr-eval. 
16.
“Jesp: JavaScript Expression Parser,” GitHub; github.com/soney/jsep. 
17.
“Chart.js: Simple Yet Flexible JavaScript Charting for Designers & Developers”; 
www.chartjs.org. 
18.
“Data Driven Documents,” 2017; d3js.org. 
19.
“SpeQ Mathematics”; speqmath.com. 
20.
“Math Notepad”; mathnotepad.com. 
21.
“Stargazers,” GitHub; github.com/josdejong/mathjs/stargazers. 
22.
“Mathjs,” NPM; www.npmjs.com/package/mathjs. 
23.
“Packages Depending on ‘mathjs’,” NPM; www.npmjs.com/browse/depended/mathjs. 
24.
“Numerics Calculator,” Optimax Software; numerics.info. 
25.
“Numerics Calculator & Converter,” Chrome Web Store; 
chrome.google.com/webstore/detail/numerics-calculator-
conve/liglcienpnkhdajdfmnpbgmpjglonipe?hl=nl. 
26.
“DuckDuckGo”; duckduckgo.com. 
27.
“Abstract Syntax Tree,” Wikipedia; en.wikipedia.org/wiki/Abstract_syntax_tree. 
28.
“Expression Trees”; mathjs.org/docs/expressions/expression_trees.html. 
29.
“Examples”; mathjs.org/examples. 
30.
“Math.js Benchmarks”; github.com/josdejong/mathjs/tree/master/benchmark. 
31.
M. Kearney, “Measure Performance with the RAIL Model”; 
developers.google.com/web/fundamentals/performance/rail. 
32.
“HTTP Archive--Interesting Stats”; httparchive.org/interesting.php. 
33.
“Custom Bundling”; mathjs.org/docs/custom_bundling.html. 
34.
“MathJax: Beautiful Math in All Browsers”; www.mathjax.org. 
35.
“Getting Math onto Web Pages Community Group,” W3C, 2017; 
www.w3.org/community/mathonwebpages. 
ABOUT THE AUTHORS