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.
By hand or regl library (almost by hand). I tried THREE, but it feels it gives me more pain than benefits (and you still end up tweaking their shaders sometimes). AI is pretty good at small tasks like tweaking shaders. I needed to draw a spectroscope, like a line connecting all pixels on the image one by one on the colorspace projection. Ended up 100 times more efficient in webgl comparing to browser API. But it is pretty low level. On another hand once you dig deeper into shaders, they are actually more powerful. Let's just say, API is just painful too :). Also, there is some fun with how transparency works and order of elements displayed (because of parallel processing). Oh, ideally I want web canvas API, but which allows to pass a buffer of lines to draw instead of one ;)
Thanks. I started getting into shaders with WebGPU, but that is not widespread yet and WebGL I did not liked, so I likely will get back to writing WebGPU shaders for better performance, once there is decent support. (And my current solution works, just could be more performant)
If GP is like me they were probably thrown off by the fact that the formatting menu is just HTML and only the cells themselves are in a <canvas> element
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'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.
I still would be interested in a use case for more stages.
My stagecanvas is the background of the html document. And there I have many layers with different zoomlevels etc
Everything pixi goes there. And can appear exactly on the screen when and where I want.
If I ever would have a use case of a second pixi layer above my html elements layer, I can do that. So I am really curious, what else one could need?
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.
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.
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
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.
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.
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
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.
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.