The counter to that is that going and looking at the call sites to that function would have given the author a better understanding of what those call sites were, why they called the function, etc, thus learning more about the codebase.
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.
Author here. It might be worth reading part 1, also.
Aside from that, yes z-index was because there are multiple SVGs rendered. We also had non-SVG stuff for each element like inputs and stuff, plus it was just like that when I got here, and it doesn’t seem unreasonable to me.
Another thing was you said it’s a problem React solves rather than creates. This is very clearly not true.
If you add event listeners to every component which is big-standard React, you end up with 1000s or tens of 1000s of event handlers often doing almost nothing. And sure, JavaScript can do 10_000 lots of almost nothing very quickly, but it’s noticeable when you’ve got a strict frame budget.
Author here. The example given is slightly contrived. A more realistic example involves large polygons that you zoom “inside” or locked elements overlaying active ones. But I had to try to give an example without a ton of context.
There are some more interesting but less easy to explain to a broad audience examples.
One is having “nearest the pointer” hovering logic rather than rectangles or circles overlaying each other.
Another is hovering line segments and the projecting the nearest hovered point onto the line. That was approximated with SVGs before and was just kind of a bug.
Another example is allowing some “wiggle room” for touching elements without having to render SVGs multiple times with transparent elements and stuff like that.
And since you mention state machines: most of the handlers are done as state machines.
Plus the overall app state is done as a kind of reverse state machine where we derive the status from various app states. I would like to change this to not be backwards one day but it was too big of a lift to change everything at once!
Author here. Absolutely right what you said about being easier to grok.
Shortly after this was merged to main (though under feature flag) another dev had to fix something and commented something like “I just fixed X in two minutes which would have taken me hours before”
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.
I don't work at Candide any more but I was CTO there when this was written. I can assure you you're reading too much into it!
Candide is very well set up to protect users' private data, and has a great set of engineers and engineering practices in place ensuring this, as well as, you know, not ever selling data to a third party!