We're working on performance-sensitive project, so one lesson we learned is that all shapes listen to all mouse events by default. We didn't even have lots of shapes, but this was enough to have a noticeable performance hit due to all the event handlers being registered. We pivoted to an opt-in approach instead and that fixed most of our problems.
Konva looks awesome, but canvas based. For more performance I switched from canvas to pixi, which is webgl/webgpu based.
Drawing can be also expensive there(in some cases even more so), but if you can manage to put it in a texture in time, you can have looooots of moving animated shapes even on mediocre mobile phones.
Konva didn't have enough performance for my use case and pixi webgl has a limit on the number of canvases on the screen at the same time
The native API is easy to use and well documented. It also performs well enough to animate charts at 60fps on modern hw for my use case. I also like that there are no libraries to update
Interaction is also supported by the API with hit regions, though I've opted to do my calculations. But I agree that interaction is where Konva would probably have shined.
But that limit is very high. What were you doing?
Hopefully webgpu would lift that limit?
Kinetic was amazing back in it's day, but lacked SVG export. I wonder if that's built-in now
There are other libs that are native SVG though, so why even use Konva? The benefit of Canvas is that it can be a lot, LOT faster than having multiple complex SVGs. SVG is especially slow on Firefox IIRC.
Would it be so difficult to crawl over a snapshot of the object hierarchy and render to a cairo-like library?
At one point I started implementing that myself using my own object representation that I had running parallel to Kinetic's internal one, but never finished it.
I can't tell if your "give up" is a reference to the "never gonna give you up" line from the rick roll video. The internet is a web of labyrinthine references, and I don't know what means what, if anything anymore.
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.
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.
I wish the performance issue were either fixed or dispelled. I think I recall some SVG performance work being done couple of years back.
It's not a fork, just a different way to build the same project.
ES2015 module is more efficient than the other formats and can facilitate the creation of smaller bundle size through tree-shaking technique.
Pixi is lower level. It takes more scaffolding to get to the same level of functionality. But it can be more performant for some draw intensive operations. Not that Konva is particularly slow though.
Recently, I started to use a bit of my company resources to improve the konva project. Currently, I am playing with AI tools for docs, so I have to pay for API usage.
No doubt this would help increase adoption these days, and make implementation a lot easier.
Instead of worrying about pixels you just mix and match vector shapes and imported rasters and turn them into declarative components that you pass props and handlers to, same as any other. Makes your Canvas a much more integrated part of your UI code than it otherwise would be.
