4 ms·

Amongst other things, the primary expense is lot of visual elements in a very dense chart that ideally would be ticking with the market in ~real time and allow

by mhh__ 2y ago

Amongst other things, the primary expense is lot of visual elements in a very dense chart that ideally would be ticking with the market in ~real time and allow more than one on the screen. A lot of it probably should be a canvas but there's a good amount of interactivity on the chart itself so moving it all over might be expensive. You obviously can bludgeon that into react but it's at the point where the diffing does seem to be non-trivially expensive and requires a bunch of nursing in the code which is frankly an insane waste of time in 2024. React is completely fine for big tables, especially if they don't actually change very much. I will also note that in turn this started out as a d3 project, react was much much faster than d3. Edit: Completely forgot to mention memory consumption. We have beefy machines so it's not really a critical problem but think of the poor caches!

solardev 2y ago
(Not that you're asking for advice, but hope you don't mind me sharing some anecdotal experience...) When we had to do similar things, we found that it was much much much faster to take all that sort of stuff out of the DOM and put it into Canvas. You can still wrap React around it for the UI and controls and data passing and all that, but the actual rendering need not involve the VDOM or even the real DOM at all. With ChartJS we were able to get it to show tens of thousands of individual data points in a time-series scatterplot, each datapoint interactive and real-time, with no noticeable lag. And it was super easy to integrate into our React app. https://www.chartjs.org/ https://www.chartjs.org/ If it's not just charts, here's another canvas-based drawing lib: https://konvajs.org/docs/sandbox/20000_Nodes.html https://konvajs.org/docs/sandbox/20000_Nodes.html (and its React tie-in: https://konvajs.org/docs/react/Intro.html https://konvajs.org/docs/react/Intro.html) Not trying to discourage you from exploring Svelte if you want to, but it might be less work to just use an existing optimized drawing lib. Regardless of the JS framework used, the DOM is going to be much slower than a Canvas.
- mhh__ 2y ago
  > Not that you're asking for advice, The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive". > canvas Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectations were historically displayed relative to current levels - but repeated ~200 times), so the existing chart libraries aren't particularly helpful and can get in the way of being able to click on stuff. Anecdotally I find that programmers are very good at writing charts for the kinds of data they understand (time series, time series of their stock options, etc), but even the "generic" (e.g. grammar of graphics) libraries can still struggle with simple combinations of those domains. Obviously you can just treat the charting library as a black-box for which you derive coordinate transformations and make things appear in the right place but not a great bus-factor for that kind of code. I use https://github.com/leeoniya/uPlot https://github.com/leeoniya/uPlot for sparklines and so on, very fast.
  - solardev 2y ago
    > It's a bespoke chart that has both temporal and non-temporal data in it Cool. That sounds like a fun project to work on! If it's not super secret stuff, I hope your company will do a write-up about it afterward.
    - mhh__ 2y ago
      I could see it happen as a carrot-and-stick for hiring perhaps, let's see.

by mhh__ 2y ago

solardev 2y ago

(Not that you're asking for advice, but hope you don't mind me sharing some anecdotal experience...) When we had to do similar things, we found that it was much much much faster to take all that sort of stuff out of the DOM and put it into Canvas. You can still wrap React around it for the UI and controls and data passing and all that, but the actual rendering need not involve the VDOM or even the real DOM at all. With ChartJS we were able to get it to show tens of thousands of individual data points in a time-series scatterplot, each datapoint interactive and real-time, with no noticeable lag. And it was super easy to integrate into our React app. https://www.chartjs.org/ https://www.chartjs.org/ If it's not just charts, here's another canvas-based drawing lib: https://konvajs.org/docs/sandbox/20000_Nodes.html https://konvajs.org/docs/sandbox/20000_Nodes.html (and its React tie-in: https://konvajs.org/docs/react/Intro.html https://konvajs.org/docs/react/Intro.html) Not trying to discourage you from exploring Svelte if you want to, but it might be less work to just use an existing optimized drawing lib. Regardless of the JS framework used, the DOM is going to be much slower than a Canvas.

mhh__ 2y ago
> Not that you're asking for advice, The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive". > canvas Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectations were historically displayed relative to current levels - but repeated ~200 times), so the existing chart libraries aren't particularly helpful and can get in the way of being able to click on stuff. Anecdotally I find that programmers are very good at writing charts for the kinds of data they understand (time series, time series of their stock options, etc), but even the "generic" (e.g. grammar of graphics) libraries can still struggle with simple combinations of those domains. Obviously you can just treat the charting library as a black-box for which you derive coordinate transformations and make things appear in the right place but not a great bus-factor for that kind of code. I use https://github.com/leeoniya/uPlot https://github.com/leeoniya/uPlot for sparklines and so on, very fast.
- solardev 2y ago
  > It's a bespoke chart that has both temporal and non-temporal data in it Cool. That sounds like a fun project to work on! If it's not super secret stuff, I hope your company will do a write-up about it afterward.
  - mhh__ 2y ago
    I could see it happen as a carrot-and-stick for hiring perhaps, let's see.