3 ms·

> looking to move it all to svelte because react literally cannot handle the quantities of data I have nothing against Svelte, but how much data are you showin

> looking to move it all to svelte because react literally cannot handle the quantities of data I have nothing against Svelte, but how much data are you showing on screen, exactly? Here's an example table with 100,000 cells (100 rows * 1000 columns per row) that seems fine, from a common React UI kit: https://mui.com/x/react-data-grid/virtualization/#column-virtualization https://mui.com/x/react-data-grid/virtualization/#column-vir... It seems fast on my computer normally (M2 Max), slow but usable when the CPU is throttled down 4x, and too slow after that. But that's a lot of cells. Here's a performance comparison, btw: https://krausest.github.io/js-framework-benchmark/2024/table_chrome_127.0.6533.72.html https://krausest.github.io/js-framework-benchmark/2024/table... Or filtered down to just Svelte vs some common React libs: https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 (lower numbers are faster; React is generally just a little slower than Svelte, except when it's swapping 2 rows in a big table... then it's 8x slower)

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.
cageface 2y ago
React is also considerably slower than svelte in this benchmark in selecting, clearing, adding and creating rows and also uses a lot more memory. For a lot of apps React is fast enough but you're definitely starting at a non-negligible performance disadvantage compared to faster frameworks.
- solardev 2y ago
  I don't know that a 15 millisecond difference in rendering performance is going to matter to anyone =/ The memory usage is in megabytes too. It's not much. For sure React is slower on paper, but in most cases it's a non-issue. Nobody chooses React for its performance benefits anyway, but because of its huge ecosystem of libs and developers. In most cases it's fast enough.
  - cageface 2y ago
    I agree that React is fast enough for a lot of things without worrying too much about performance. I've also worked on several apps where we had to work really really hard to get decent performance out of React and the resulting code was ugly and brittle.
  - LtWorf 2y ago
    The fact that it's fast enough on your 2000$ machine doesn't really tell us much.
    - solardev 2y ago
      I was using the numbers from the benchmark, which wasn't my machine, and was sometimes throttled down.
treyd 2y ago
I don't know what GitHub projects uses but we have ~200 tickets in it and it absolutely chugs. Even typing text into new entries will regularly hang for multiple seconds every few words.
anonymoushn 2y ago
It's defective because the browser's find feature does not work.
- solardev 2y ago
  Good catch! I didn't realize that about this lib. It has some consideration for what it calls "overscanning", but that only extends a little bit past the current view.
funcDropShadow 2y ago
> Here's an example table with 100,000 cells ... > It seems fast on my computer normally (M2 Max), slow but usable when the CPU is throttled down 4x, and too slow after that. But that's a lot of cells. No, it is not a lot of cells in a table. It is something a Windows95 era PC had no problem doing in something like Delphi Builder. And you find it acceptable that it slows down, if an M2 Max throttles down? Even a throttled down M2 Max is supposed to be 1000x (obviously an exageration, because I am to lazy to apply Moore's Law more rigorously on a Sunday morning) faster than an Intel 486DX. Where did all the compute power go? Are we really using the right tools for our jobs?
- solardev 2y ago
  I think all software is a balance of factors, from performance to ease of use to DX to maintainability, cost, etc. I don't think most tables need to be as peformant as possible, especially when a slow render is still measured in sub-seconds. That level of performance is totally fine for many use cases. If you have a special need for large datasets, yes, you should pay more attention to how that's optimized. But for your average bog standard web app, I think any framework will be just fine, performance wise, on any 10 ish year old device. If it's slow, it's more likely because of ads, tracking, large media, poor caching, distance from a CDN, etc. Especially since React these days is typically rendered to HTML during the build anyway and then rehydrated for interactivity later. React isn't a performance optimization to begin with, but a DX improvement and architecture abstraction lib (vs vanilla or jQuery). It makes some apps much easier to write and maintain across generations of low cost developers. The performance is a small sacrifice, but it's usually not even noticeable. For performance critical apps, probably you'd just bypass the DOM anyway and draw to canvas instead, and offload all the heavy processing to wasm. Yeah, compared to the 90s, our computers and modems are much faster and used less efficiently. But there are billions more users and millions more developers of various skill levels now, and that's just a tradeoff we get for mass adoption. It's no longer just a tool for elites, but just another tool in the office, and often times a race to the bottom like anything else in business (in terms of React devs being low cost commodities). A small React team can put together a functional app much quicker and cheaper than with vanilla, at the cost of some usually negligible performance. Probably a good tradeoff for most apps. If you're talking about web apps in general, compared to desktop or CLI apps, then yeah, I agree that it's a bit of a shame this is what won the desktop platform wars. At least on mobile we have native apps (which often feel much faster than anything web based), so there's that at least.

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.

cageface 2y ago

React is also considerably slower than svelte in this benchmark in selecting, clearing, adding and creating rows and also uses a lot more memory. For a lot of apps React is fast enough but you're definitely starting at a non-negligible performance disadvantage compared to faster frameworks.

solardev 2y ago
I don't know that a 15 millisecond difference in rendering performance is going to matter to anyone =/ The memory usage is in megabytes too. It's not much. For sure React is slower on paper, but in most cases it's a non-issue. Nobody chooses React for its performance benefits anyway, but because of its huge ecosystem of libs and developers. In most cases it's fast enough.
- cageface 2y ago
  I agree that React is fast enough for a lot of things without worrying too much about performance. I've also worked on several apps where we had to work really really hard to get decent performance out of React and the resulting code was ugly and brittle.
- LtWorf 2y ago
  The fact that it's fast enough on your 2000$ machine doesn't really tell us much.
  - solardev 2y ago
    I was using the numbers from the benchmark, which wasn't my machine, and was sometimes throttled down.

treyd 2y ago

I don't know what GitHub projects uses but we have ~200 tickets in it and it absolutely chugs. Even typing text into new entries will regularly hang for multiple seconds every few words.

anonymoushn 2y ago

It's defective because the browser's find feature does not work.

solardev 2y ago
Good catch! I didn't realize that about this lib. It has some consideration for what it calls "overscanning", but that only extends a little bit past the current view.

funcDropShadow 2y ago

> Here's an example table with 100,000 cells ... > It seems fast on my computer normally (M2 Max), slow but usable when the CPU is throttled down 4x, and too slow after that. But that's a lot of cells. No, it is not a lot of cells in a table. It is something a Windows95 era PC had no problem doing in something like Delphi Builder. And you find it acceptable that it slows down, if an M2 Max throttles down? Even a throttled down M2 Max is supposed to be 1000x (obviously an exageration, because I am to lazy to apply Moore's Law more rigorously on a Sunday morning) faster than an Intel 486DX. Where did all the compute power go? Are we really using the right tools for our jobs?

solardev 2y ago
I think all software is a balance of factors, from performance to ease of use to DX to maintainability, cost, etc. I don't think most tables need to be as peformant as possible, especially when a slow render is still measured in sub-seconds. That level of performance is totally fine for many use cases. If you have a special need for large datasets, yes, you should pay more attention to how that's optimized. But for your average bog standard web app, I think any framework will be just fine, performance wise, on any 10 ish year old device. If it's slow, it's more likely because of ads, tracking, large media, poor caching, distance from a CDN, etc. Especially since React these days is typically rendered to HTML during the build anyway and then rehydrated for interactivity later. React isn't a performance optimization to begin with, but a DX improvement and architecture abstraction lib (vs vanilla or jQuery). It makes some apps much easier to write and maintain across generations of low cost developers. The performance is a small sacrifice, but it's usually not even noticeable. For performance critical apps, probably you'd just bypass the DOM anyway and draw to canvas instead, and offload all the heavy processing to wasm. Yeah, compared to the 90s, our computers and modems are much faster and used less efficiently. But there are billions more users and millions more developers of various skill levels now, and that's just a tradeoff we get for mass adoption. It's no longer just a tool for elites, but just another tool in the office, and often times a race to the bottom like anything else in business (in terms of React devs being low cost commodities). A small React team can put together a functional app much quicker and cheaper than with vanilla, at the cost of some usually negligible performance. Probably a good tradeoff for most apps. If you're talking about web apps in general, compared to desktop or CLI apps, then yeah, I agree that it's a bit of a shame this is what won the desktop platform wars. At least on mobile we have native apps (which often feel much faster than anything web based), so there's that at least.