I joined a project last year which uses Konva inside an Angular application. It was my first time doing any kind of canvas programming, but the ergonomics of konva can be picked up quite rapidly and I've been enjoying quite a lot.
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.
I evaluated this vs pixi and native canvas API. In the end I decided to use native API.
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
What was your use case? Konva is a pretty high level abstraction, more like a lightweight interactive geometry & paint engine than a graphics API. It must've taken quite a bit of work to recreate similar functionality using native APIs?
I discovered Konva just this week and it has been extremely helpful for jumpstarting my latest project. I've been impressed with the docs and the examples and the ergonomics of the api giving me an unusual amount of "it just works" moments.
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.
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.
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
I've used PixiJS and react-pixi-fiber to write a declarative 2D WebGL renderer in React with excellent results. PixiJS also has a Canvas2D fallback when WebGL isn't available. I wonder how this compares.
Konva is much easier to use for simpler apps, especially combined with React. You basically define some shapes similarly to how you would declare any component, pass props and event handlers to it, and it just magically works.
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.
I once tried creating a table component but couldn't solve the issue of having bad font quality when zooming into the canvas. I guess I would have needed to re-render things or so.
A high level simple interactive graphics and shapes library for JS, including a React adapter, that make it much easier to build graphical dashboards, visualizations, charts, simple games, etc.
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.
sebdufbeau|11 months ago
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.
lukan|11 months ago
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.
https://www.goodboydigital.com/pixijs/bunnymark/
h1fra|11 months ago
polskibus|11 months ago
zareith|11 months ago
salojoo|11 months ago
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
solardev|11 months ago
lukan|11 months ago
But that limit is very high. What were you doing?
https://www.goodboydigital.com/pixijs/bunnymark/
collingreen|11 months ago
Fauntleroy|11 months ago
peterpost2|11 months ago
stephenhandley|11 months ago
recroad|11 months ago
tetris11|11 months ago
Kinetic was amazing back in it's day, but lacked SVG export. I wonder if that's built-in now
afavour|11 months ago
lavrton|11 months ago
jonplackett|11 months ago
grav|11 months ago
gedy|11 months ago
zdragnar|11 months ago
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.
ayhanfuat|11 months ago
leptons|11 months ago
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.
spankalee|11 months ago
I wish the performance issue were either fixed or dispelled. I think I recall some SVG performance work being done couple of years back.
solardev|11 months ago
rk06|11 months ago
tbo47|11 months ago
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.
https://github.com/konvajs/konva/issues/1829
unknown|11 months ago
[deleted]
slig|11 months ago
your_challenger|11 months ago
vile_wretch|11 months ago
robertlagrant|11 months ago
probabletrain|11 months ago
solardev|11 months ago
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.
recroad|11 months ago
rapnie|11 months ago
lavrton|11 months ago
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.
Ezhik|11 months ago
I_am_tiberius|11 months ago
boomskats|11 months ago
arskeliss16387|11 months ago
admiralrohan|11 months ago
solardev|11 months ago
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.