They could have written their own event system for SVG (e.g. using event handlers on document), which would have fixed the gripes they blamed on SVG events. They wrote their own event system for canvas, so probably not much more difficulty in coding work?
Performance is the remaining issue that isn’t clear that SVG would meet. I assume SVG painting could be as fast as canvas painting. I am assuming if you attach no events to SVG elements, you remove the event performance issues (well, replace them with performance issues in your own custom event handlers, but no worse than canvas). Surely removing all the now unneeded SVG-grab-handle-elements (“DragBox”) that were only there to capture events would also improve performance (painting and event capture). Canvas is using imperative drawing primitives, and SVG can use composable primitives - both can be rendered by GPU. Canvas updates (eg. during dragging) require heavier imperative updates, while SVG primitives can theoretically be offloaded to the GPU. I can’t guess performance differences and performance delta probably strongly depends on browser, driver, and GPU.
Assuming you write your own event handling stack:
> the mouse only hits SVG elements inside their painted region
Fixed (as good as canvas)
> we could use things like pointer-events to disable certain interactions at certain times
Unnecessary (plus lowers stress on rendering?)
> Having every element produce a whole load of DOM elements for React to manage becomes a problem for performance when every element attaches event handlers, has to manage their lifecycles, observe state, etc., etc.
Fixed with document events
> Interactivity limitations. With our SVG renderer, each element managed its own interactions, which made it impossible to drag elements that were underneath other elements. This is a surprisingly common when making complex maps.
Fixed with document events
> Maintainability. However, with every element attaching its own interactions, there is a tendency for every interaction to know about every other, checking if it should be enabled or not.
Fixed with document events
> Another maintainability issue is the proliferation of event.stopPropagation() calls in the code. These are to stop events bubbling up through the complex DOM structure and allowing other components to handle events.
Fixed with document events (equivalent difficulty to canvas).
When writing complex code you learn that stopPropagation() is evil. Writing code to avoid it requires skills. IMHO stopPropagation should never be in any complex codebase (or perhaps with rules to prevent errors).
> We also have a few places where we have awkward setTimeout() calls
Oh my god, no! Terrible hack with terrible consequences, as they discovered. setTimeout() introduces very evil race-conditions, and testability issues. An alternative which isn’t much better is to use async to get microtasks, so at least you are not reordering events/tasks. IMHO in any modern codebase setTimeout should be banned or extremely restricted when it is absolutely needed.
SUMMARY
Basically, it sounds like the team needs some more experienced GUI developers.
I would bet good money they are trading one set of problems for another, and ending up with a codebase that is less maintainable.
I can only hope the article is not written by the lead developer - heaven help them if it were.
Opinions are my 10c as a custom framework developer (admittedly only one product that was not as complex as a GUI editor - that is why the inexpert mistakes sound so painful to me - although I could also avoid and detect problems because it was my own framework: depending on a third party framework makes it a heap harder to fix systematic faults).