[zdragnar]

Take react / svelte/ etc out of the equation. The important question is why would you use canvas vs svg?

As a sibling comment noted, number of elements can be a big performance drag, since they all add weight in the DOM. Other considerations are animations- it's been a few years, but I recall a number of animations in SVG that would utterly destroy browser performance (I think it was animating a stroke with CSS but I could be wrong here).

There's a sibling trend of animation editors exporting to wasm/canvas as well; see for example Lottie and Rive.

Having settled on SVG vs canvas, and presuming you chose canvas, if you're already in react / svelte / etc, this library gives you a way to do so that fits in with what you're already doing.

[gedy]

I understand that, though this is not direct canvas access and manages a number of components to handle each shape. I'd assume this introduces some overhead too.

[zdragnar]

Certainly, but if you aren't willing to accept overhead, none of these frameworks are all that great.

That said, unless you absolutely can't handle the overhead, it's usually worth the penalty. The canvas API is fully imperative, which really conflicts with the style of a component based architecture.

Finally, while it is possible to hand-roll something faster, it's also possible to make mistakes and undermine the performance of the rendering pipeline on your own. If you have something complex enough to warrant this library, you're likely to end up rolling your own abstractions for things anyway.