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.
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.
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.
Main advantage of canvas is performance. If you have thousands of elements or if you are doing some complex animations SVG may become a performance bottleneck but in general it is a simpler solution that does the job.
I built a web app (started about 7 years ago) that had used hundreds up to about 2000 DOM elements that are all draggable with lots of interactivity. The app slowed to a crawl. I used DOM elements at the time knowing it was going to be difficult to scale up to thousands of items. Using React-dnd to make the elements draggable may have been the wrong way, but it was fine for proof-of-concept. But eventually it became a gigantic memory hog and would crash the browser after a while.
Konva.js solved the issue for me. It was very easy for me to convert this entire interactive piece into Konva.js, and performance is amazing. No memory issues now at all, and I can throw thousands more interactive items than I could before. It was very easy to reuse the interactivity code with Konva, and now my web application has great performance again.
Yes I'm sure canvas is still quick, but I've run into teams doing really elaborate things in canvas, d3, etc for what amount to really simple graphs where they'd have been much better off with normal DOM elements and events in SVG.
Canvas can be quick yes, but I was surprised recently when I tried converting an animated image overlay thing I had written in SVG to canvas. I was expecting huge speedups, but it was no faster or smoother with the same data model. I needed mouse interactions as well and was nice to have normal events for these.
If you have a few interactive elements, maybe even a few hundred or so, then SVG can work just fine. I had thousands of interactive elements, and using DOM elements (including SVG) caused massive slowness and memory issues. Konva.js solved all of that for me, it's extremely performant even with thousands of interactive elements.
it is not that people would chose svg inside react/vue but that people want react/vue to manage svg for the same reason as we use react/vue to maange html
