Konva.js - Declarative 2D Canvas for React, Vue, and Svelte
75 comments
·March 19, 2025sebdufbeau
lukan
"We're working on performance-sensitive project"
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.
h1fra
Don't know about the library but the spreadsheet project built on top is impressive https://www.rowsncolumns.app/
polskibus
That component is not built on Konva though. Canvas has long been known to be the perf endgame for web, see google sheets etc .
zareith
Unrelated tangent, but $300 for non-commercial use with limited features... wow!
salojoo
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
solardev
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?
salojoo
I'm rendering charts. The native API conveniently provides the fundamentals with lines and rectangles. In addition masking and text have been very useful.
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.
lukan
"pixi webgl has a limit on the number of canvases on the screen at the same time"
But that limit is very high. What were you doing?
salojoo
The amount of concurrent webgl canvases on a page is limited by browsers. I believe it's somewhere between 8-20 depending on the browser.
Hopefully webgpu would lift that limit?
lukan
I guess, the trick is to keep everything inside on stage. But why would I need more than 8 stages?
I have allmost unlimited pixi containers.
(And HTML and sometimes a ordinary canvas on top of my pixi canvas)
collingreen
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.
Fauntleroy
The site and docs for Konva are conspiciously pleasant and well fleshed out. The "price" link jumpscare is also something I haven't yet seen.
peterpost2
The pricing page is well done indeed.
mklarmann
impressive! But know I am left wondering, what the price is...
stephenhandley
Agreed, love how clear their pricing page is.
recroad
I PoC'd this and ended using PhaserJS for the 2D stuff I had to do - it's more game-oriented by much more full-featured. The API is intuitive as well.
tetris11
Is this the successor library for KineticJS and ConcreteJS?
Kinetic was amazing back in it's day, but lacked SVG export. I wonder if that's built-in now
afavour
SVG export feels like it would be borderline impossible. Raster graphics to vector?
solardev
The underlying shapes are defined by geometries (so vectors) and then rasterized to canvas. So the SVG export could happen before the rasterization.
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.
tetris11
SVG purely for image export, I'm not talking about animation features.
Konva to set the scene, SVG for final touches before you publish the image somewhere
simonsarris
I make a canvas-based diagramming library (GoJS) and implemented SVG export, and then a whole SVG renderer if you want the same scene in real-time. Generally if you're using HTML Canvas commands, you can engineer a perfect SVG equivalent. There are some really really really annoying edge cases with transforms, clipping, gradients, etc. But nothing is impossible :D
null
lavrton
It is a fork of KineticJS. SVG export isn't implemented and I don't think it will be. I, personally, see it as out of the focus of the project.
tetris11
We used Kinetic a lot for a specific type of visual analysis we had, but when it came to creating publish-worthy figures, working with PNG screenshots was less than desirable.
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.
jonplackett
Pricing is unbelievable
grav
I give up, why?
solardev
It's FOSS. And you get rickrolled by the pricing link.
steve_adams_86
Never give up! https://www.youtube.com/watch?v=KxGRhd_iWuE
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.
null
gedy
For folks who have used this, why would you choose this instead of SVG inside React, Svelte, etc?
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.
ayhanfuat
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.
leptons
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.
spankalee
That's my question, because SVG is declarative vector graphics. It has a ton of features, can be SSR'ed, written and used in various apps...
I wish the performance issue were either fixed or dispelled. I think I recall some SVG performance work being done couple of years back.
gedy
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.
solardev
It is much much MUCH faster. SVGs really slow down on some browsers (especially Firefox) after a certain level of complexity and interactivity.
gedy
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.
leptons
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.
tbo47
Konva at esm format https://www.npmjs.com/package/konva-es
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.
null
slig
I made a jigsaw puzzle (featured in the Konva's home page) years ago. Recently did a full conversion to ReactKonva using Claude and it's a breeze.
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.