We solved this issue by using a rendering engine that has rich tooling, strong profiling and inspection capabilities, and is centered around predictability - React.
D3 v4 provides all of its goodness in loosely coupled modules with clear boundaries, so you can use it for all heavy lifting that it's amazing at (layouts, animations, shapes), then setState() all over the place to reflect the results in the DOM. Performance wise, the only limits we are hitting are native SVG limits on the number of nodes.
Our visualisations are complex (science and finance, to an expert and expertly distracted audience), but no more complex than the rest of the app. React paradigm is predictable, well known, and has a deep user base to lean on. Performance and inspection tools are solid. And the only difference is that the render method has a <g> instead of a <div>.
I’ve done similar things with React and SVG and I concur. As with scaling anything up using React, you need to be careful about how you structure your components so you can write shouldComponentUpdate everywhere you need it to get acceptable performance. That in turn means you have to be careful about how you represent the underlying data and any further data you derive from it to use when rendering your SVG. However, assuming those things have been done, I have found React+SVG to be a reasonably effective combination so far.
Why couldn't you achieve the same exact thing using a more traditional API, such as 2D/3D drawing?
I just don't see the huge value add. I've been doing visualizations for years and I think its way easier to just have a render loop that interacts directly with the graphics hardware via API based upon a current state that is being expressed for a given frame. You are free to structure your code however you wish and have none of the weird abstractions that come along with something like a declarative syntax like SVG. Not everything is well suited for a neat and orderly hierarchical abstraction and forcing yourself to adopt this abstraction for every project makes the code more complex.
I do think SVG is a good universal serialization format for most vector graphics, but if you're operating on data using SVG ends up (eventually) being more of a crutch than a help. If you don't believe me wait a year and look how complicated and convoluted your code will become.
D3 v4 provides all of its goodness in loosely coupled modules with clear boundaries, so you can use it for all heavy lifting that it's amazing at (layouts, animations, shapes), then setState() all over the place to reflect the results in the DOM. Performance wise, the only limits we are hitting are native SVG limits on the number of nodes.
Our visualisations are complex (science and finance, to an expert and expertly distracted audience), but no more complex than the rest of the app. React paradigm is predictable, well known, and has a deep user base to lean on. Performance and inspection tools are solid. And the only difference is that the render method has a <g> instead of a <div>.