By a custom renderer, are you referring to replacing the rendering process (e.g. ReactDOM) rather than replacing JSX?
It's not clear to me how this would be better than swapping out the @jsx pragma. For rendering content to the Canvas, we have no need for all the overhead and complexity of React elements/components. There is no need or benefit in using the `React.createElement` (or its newer counterparts) to create React elements. But in theory, you're right that CanvaSX could have used React elements and rendered those instead of replacing the JSX pragma.
`react-canvas` definitely has a lot of similarities, but it is very old, uses class-based components, uses React elements, and most importantly, it doesn't provide any auto-layout functionality out of the box.
The main driving factor behind CanvaSX was the auto-layout functionality: if you look at the example code for rendering a button using CanvaSX, you'll noticed that there are no positional or coordinate properties being defined. In `react-canvas`, the coordinates/dimensions of each shape must be manually defined, which becomes problematic for shapes with dynamic content being rendered inline. `react-canvas` did not attempt to solve any of those problems, CanvaSX does.
CanvaSX currently doesn't have its own rendering event loop or anything like that, it simply renders everything that is passed in. For now this makes the implementation very simple and naive.
Internally we are using this for our Aha! Whiteboards product, which is built on top of Fabric.js The Fabric framework provides a lot of the rendering optimizations out of the box: it will only render shapes that are visible in the current viewport. Fabric resets and re-renders the entire canvas every time, but it will only re-render as needed. There are also instances where we need to manually trigger a re-render based on state changes to the whiteboard.
So the rendering performance thus far has not been an issue. We are always looking for improvements to our product and the implementation of CanvaSX, but we didn't want to prematurely optimize or over-engineer the framework.
Perhaps I could have shared more details on this. We did explore regular DOM/HTML for some of the functionality, but we needed to build it into our existing Whiteboards stack which uses Canvas. Rendering as HTML would not have worked for use case.
I've been using semantic variables for years, but they were always defined in Sass/LESS. With this approach and using CSS variables, it's really easy to have the same semantic palette, but then define different themes. Nice!
It's not clear to me how this would be better than swapping out the @jsx pragma. For rendering content to the Canvas, we have no need for all the overhead and complexity of React elements/components. There is no need or benefit in using the `React.createElement` (or its newer counterparts) to create React elements. But in theory, you're right that CanvaSX could have used React elements and rendered those instead of replacing the JSX pragma.