Hoo, boy... there's an entire book to write on that topic. Honestly, it doesn't matter while your performance is acceptable for your intended audience.
It depends on how efficient you require the code to be. Does it have to run at huge resolutions on tiny devices, or is it just a framerate insensitive toy to be run on the desktop? Depending on those factors, you might want to consider a general mechanism (SVG vs. 2D canvas vs. WebGL vs. generating byte arrays in WASM, etc.), then choose the library that can perform that, depending on your workload.
I usually choose something I can cleanly express my problem in, and if that becomes a bottleneck, I build the code in such a way that the rendering is completely decoupled from the library, so I can switch it out for anything else in the future.
And just to note, the bottleneck in this simulation is the inefficient O(n^2) requirement for calculating forces between non-connected cells. The rendering is really not the slowest part of this algorithm. You'd have to look into things like space partitioning (quadtrees) and offloading calculations to the GPU (GPGPU) to ever reach speeds that would make rendering the bottleneck. So in this case, it really doesn't matter what I use for rendering, as rendering will grow approximately linearly with the number of particles (O(n)).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hoo, boy... there's an entire book to write on that topic. Honestly, it doesn't matter while your performance is acceptable for your intended audience.
It depends on how efficient you require the code to be. Does it have to run at huge resolutions on tiny devices, or is it just a framerate insensitive toy to be run on the desktop? Depending on those factors, you might want to consider a general mechanism (SVG vs. 2D canvas vs. WebGL vs. generating byte arrays in WASM, etc.), then choose the library that can perform that, depending on your workload.
I usually choose something I can cleanly express my problem in, and if that becomes a bottleneck, I build the code in such a way that the rendering is completely decoupled from the library, so I can switch it out for anything else in the future.
And just to note, the bottleneck in this simulation is the inefficient
O(n^2)requirement for calculating forces between non-connected cells. The rendering is really not the slowest part of this algorithm. You'd have to look into things like space partitioning (quadtrees) and offloading calculations to the GPU (GPGPU) to ever reach speeds that would make rendering the bottleneck. So in this case, it really doesn't matter what I use for rendering, as rendering will grow approximately linearly with the number of particles (O(n)).