Unsure if the simulation is decoupled from the display, but it gets a little slow in graphical mode in Firefox. Could be a really interesting WebAssembly optimization project.
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.
It seems there are just simply too many elements generated for some of the examples.
It would probably be possible to draw an interactive version to a single canvas— but probably more complex on the development end.
---
Beyond that, it's awesome!
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.
Canvas is another type of abstraction - and blitting to the screen is easier with it - so same applies.
It runs faster for me in chrome and firefox in linux