[HN Gopher] Konva.js - Declarative 2D Canvas for React, Vue, and...
___________________________________________________________________
Konva.js - Declarative 2D Canvas for React, Vue, and Svelte
Author : lavrton
Score : 194 points
Date : 2025-03-19 12:30 UTC (10 hours ago)
(HTM) web link (konvajs.org)
(TXT) w3m dump (konvajs.org)
| arskeliss16387 wrote:
| Looks promising and quite handy for my project
| sebdufbeau wrote:
| 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.
| lukan wrote:
| "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.
|
| https://www.goodboydigital.com/pixijs/bunnymark/
| graftak wrote:
| Impressive, it took me 113K bunnies for a single frame drop
| on an iPhone 14pro
| Fauntleroy wrote:
| 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 wrote:
| The pricing page is well done indeed.
| mklarmann wrote:
| impressive! But know I am left wondering, what the price
| is...
| admiralrohan wrote:
| What is the purpose? React for Canvas tag?
| solardev wrote:
| 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.
| gedy wrote:
| For folks who have used this, why would you choose this instead
| of SVG inside React, Svelte, etc?
| rk06 wrote:
| 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
| solardev wrote:
| Konva-React basically gives you the same ergonomics
| (declarative shapes as React components) without the
| performance penalty of SVGs.
| ayhanfuat wrote:
| 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.
| zdragnar wrote:
| 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 wrote:
| 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 wrote:
| 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.
| spankalee wrote:
| 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 wrote:
| 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 wrote:
| It is much much MUCH faster. SVGs really slow down on some
| browsers (especially Firefox) after a certain level of
| complexity and interactivity.
| gedy wrote:
| 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 wrote:
| 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.
| gedy wrote:
| That's helpful to hear, thanks
| leptons wrote:
| 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.
| h1fra wrote:
| Don't know about the library but the spreadsheet project built on
| top is impressive https://www.rowsncolumns.app/
| polskibus wrote:
| That component is not built on Konva though. Canvas has long
| been known to be the perf endgame for web, see google sheets
| etc .
| lavrton wrote:
| It is Konva. You can inspect it in Dev Tools.
| culi wrote:
| 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
| rapnie wrote:
| Is this a community-driven project, or is there a company behind
| the project?
| lavrton wrote:
| It is mostly community-driven.
|
| 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.
| vekker wrote:
| I'd highly recommend to add an "LLM Cheatsheet" page to your
| docs. Example: https://goatdb.dev/llm-cheatsheet/
|
| No doubt this would help increase adoption these days, and
| make implementation a lot easier.
| vile_wretch wrote:
| I used this for a project a few years ago. It's quite intuitive
| and made developing a workflow/graph editor a relative breeze.
| your_challenger wrote:
| I haven't tried Konva. But have been using fabric js for an image
| editor I've been working on. I guess they both do a good job.
| tetris11 wrote:
| 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
| lavrton wrote:
| 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 wrote:
| 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.
| afavour wrote:
| SVG export feels like it would be borderline impossible. Raster
| graphics to vector?
| solardev wrote:
| 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 wrote:
| 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
| solardev wrote:
| Seems like you could just use Figma if you want to build
| a static SVG for export. Konva is more for building
| interactive apps.
| boomskats wrote:
| How does this compare to tldraw in terms of featureset / target
| market?
| probabletrain wrote:
| 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.
| solardev wrote:
| 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.
| recroad wrote:
| PixiJS is too low level for anyone who wants to get something
| up quickly. For example, you have to implement your own
| dragging code (ew).
| Ezhik wrote:
| Reminds me of p5.js - I still fall back to it to do some quick
| graphics.
| salojoo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "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?
|
| https://www.goodboydigital.com/pixijs/bunnymark/
| diath wrote:
| Those are just sprites rendered onto the same canvas, not
| multiple canvases.
| lukan wrote:
| The idea with pixi is, that you have one HTML canvas. But
| every sprite can also be a graphics object/canvas.
| phil-martin wrote:
| Which makes it ill-suited when you need multiple
| canvases. Pixijs is amazing, and I mix Pixi, Fabric and
| regular canvases in my application.
| salojoo wrote:
| 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 wrote:
| 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)
| slig wrote:
| 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.
| jonplackett wrote:
| Pricing is unbelievable
| grav wrote:
| I give up, why?
| solardev wrote:
| It's FOSS. And you get rickrolled by the pricing link.
| steve_adams_86 wrote:
| 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.
| collingreen wrote:
| 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.
| robertlagrant wrote:
| Such a catchy pricing page!
| I_am_tiberius wrote:
| 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.
| recroad wrote:
| 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.
___________________________________________________________________
(page generated 2025-03-19 23:00 UTC)