The rendering slowness is probably because every cell is rendered as an individual little HTML5 canvas (two, one for off state and one for on state).
Some browsers have no problem at all with so many little canvases, but in firefox it causes a slowdown.
A solution that will hopefully be faster is to make one big canvas instead of many little ones, and blit the cells on it every frame instead of using CSS visibility to swap between on and off states for each cell. Such rewrite of the rendering engine is a todo.
The problem here is not a lack of framework, but the overkill usage of elements.
I think even a game-like approach of using a single canvas and re-rendering the whole screen when something changes would be more efficient than manual DOM mutations.
Wasn't snark, Mr Hostility. DOM manipulation is a very expensive operation and is abstracted by a lot of useful libraries - was wondering if there was a specific reason to not use them.
Canvas is another type of abstraction - and blitting to the screen is easier with it - so same applies.
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.
It runs faster for me in chrome and firefox in linux