[hicksyfern]

Author here.

I know this is the orange site and we have to expect this type of comment, but still…

I’ve been building software for more than 20 years, and using React since it came out.

You’re right that this event handling system isn’t exclusive to canvas. But then I’m not sure if you read the first part of the article where we talk about the other big reason: performance.

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.

You also neglect the fact (and this also points to your immaturity) that products are built by a number of people over a long period of time, with different constraints on them as things change.

The SVG approach was done for good reasons and the code made sense for what it was for initially. Then things got more complex and people started making more complex maps.

What we also found is that the complexity of maps people made increases with our performance gains: the faster the app is, the more people do with it.

I haven’t got time to go into everything either in the articles or certainly this reply, but I’d ask you to have a look at yourself and decide if you really want to be That Guy on HN.

[robocat]

Yeah, I should not have been so inflammatory and I should have limited my comments to where I have deep experience.

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?).

[hicksyfern]

Appreciate the response.

The thing is, for a lot of it I can’t go into huge amounts of detail otherwise I could write a book on it.

You’re right that the interaction system could keep the SVG as a renderer, and I don’t remember whether that point ended up in the final version! But I have done that locally just for fun to see if it works and it does.

I can give you one example of something that’s too much to go into in a high-level article: SVG and canvas are both very slow at drawing dashed lines. With mapping software, the overall zoom level gets to something like 50 million percent or something ludicrous, and what that means is often you have literal kilometres of dashed lines drawn off screen just if one pixel is on screen for that geometry.

With SVG the only real way to get good perf is to use transforms to move things around when you’re not zooming, or scale them when you are. This doesn’t work if you then need to viewport-clip your lines – you need to render every frame and that gets really slow. With canvas it’s just not a problem, I guess partly because you’re not always making enormous path strings on every frame.

Another example is viewport culling. To avoid thrashing the DOM as you zoom, you don’t really want to be adding and removing elements because it gets janky. We had a viewport culling solution in SVG land with a big dynamic CSS style switching each element on and off which alleviated the browser’s painting workload but it feels hacky as hell. With canvas, you just intersect the viewport with the world and that’s your display list so you render each element in that list. Much simpler model.

Seriously there’s so much involved in making this stuff work well I could literally write a book, but I had to settle for a 2 part article where I had to pick the simplest examples and shortcut some of the detailed explanations.

After all, it’s just a dev blog not an academic paper.