From SVG to Canvas – A new way of building interactions

The comments on preventDefault() and setTimeout() in particular repeat my own hard-won experiences: it is unfortunate you had to experience the same pain.

In the previous article, maybe the first third is you fighting your framework, which is admittedly what happens to us all if we are on the bleeding edge with performance issues. Certainly you are not the first team to find that canvas is a better solution.

In the first article you say “whenever the element’s coordinates or the viewport changed, we would re-render the element”, and you go on to talk about SVG versus canvas. HOWEVER it is impossible to tell whether your underlying performance problems actually stem from SVG (or SVG+events, or SVG+React). I can believe that canvas is more performant and more predictable, but your first article lacks enough detail to actually blame SVG. DOM changes, React, JavaScript could and probably did have severe impact on overall performance. That was the point I tried to make (admittedly, very poorly, since it isn’t clear you could avoid DOM changes in particular).

My main gripe with your second article was that you were concentrating on problems to do with SVG events and React - a problem that you resolved with your own event stack on canvas. That solution could have worked for SVG, although as you wrote in your first article, would not resolve your performance problems when painting.

> Your assertions that setTimeouts should be banned show immaturity. There are some cases where certain browsers do things in a different order and you really are required to use a hack like that.

I guess I had that coming, but I stand by the statement. I learnt about setTimeout(0) caused-problems when working with DHTML controls (pre-frameworks) and frameworks that had nasty heisenbugs: intermittent hard-to-reproduce bugs that would surface because of events racing timeouts. One reason for writing a custom framework was that it was more reliable for users than depending on code that was out of our control: just the same as you are writing about. The framework KendoUI had been chosen by another at one point, and it was particularly troublesome for me. I believe using setTimeout() to avoid browser bugs is diabolical (or framework bugs even worse), because all too often you end up with further troubles that can be extremely hard to reproduce or diagnose. I worked hard to avoid setTimeout(), replumbing code at times, but it virtually always could be avoided with enough work (especially with complete control over event handlers). I stand by “setTimeout should be banned or extremely restricted when it is absolutely needed” because setTimeout(0) is a plaster that too many developers use to paste over cracks. Yes, browsers sometimes force us to accept the ugliest of hack solutions, to achieve some usability goal or avoid some browser bug.

All the best. Without a doubt you are far more experienced than I in this area, and certainly you have had a ton of experience wrestling with canvas versus SVG, and I certainly appreciate your article about how you won using canvas. Fighting performance problems in browsers requires a certain intransigence and flexibility, and I feel your pain and your glory from my own past experiences doing the same.

(Edited to add extra depth and details). I think that I was so skeptical because the articles lack many technical details that compare SVG performance versus canvas. It compares a React+SVG codebase, with a rewritten canvas codebase. I can believe that SVG is worse than canvas, but neither article has much that is convincing on that point except that the rewrite was successful (which is admittedly a good prior that canvas is better). it is possible you are too quick to dismiss the experience of others. Background: I was nearly 100% focused on front end work, mostly heavy DOM/JavaScript from 2006 for a bit over a decade; but I have worked in a variety of software dev roles for a few decades (embedded, DB, client-server, Windows apps, front-end, POS, plus other random bits). I can definitely say I am well above average at writing reliable, performant, usable code (maybe due to my embedded programming background?).

Not ironic, expected. When you do a refactor like this any good PM knows you’re creating a bunch of new bugs, and the ROI of the rewrite should consider this.

Unfortunately the way it goes most of the time is “ok, what if we’re really careful not to write any bugs? Then it’s all upside!”

…and now your dark theme is broken

> One particularly nice aspect of this system is that key presses follow the same flow as pointer events, which is not how things work in the DOM. In the DOM, you usually bind key handlers globally, and pointer events per element. But here, we get all the benefits of stopping propagation centrally, which is a real help for adding keyboard shortcuts and modifier keys.