3 ms·

> 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

> 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.
- Thro4l31 2y ago
  I think this all is true. No idea why the downvotes.
pfix 2y ago
In general I agree with your sentiment. But here we are in a browser environment so we should compare performance to a raw HTML table. And then complain if the raw HTML is still slower than Delphi on win95 because HTML tables have been around since back then :D
rtpg 2y ago
> It is something a Windows95 era PC had no problem doing in something like Delphi Builder. I would recommend you actually try this, because it's not as true as you would like to believe. I am very much pro-"make things fast" but let's not pretend that old machines didn't randomly hiccup on things all the time as well.
- stoperaticless 2y ago
  Well. If it was bearable then, with 2x powerful pc, it should be much better.

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.

Thro4l31 2y ago
I think this all is true. No idea why the downvotes.

pfix 2y ago

In general I agree with your sentiment. But here we are in a browser environment so we should compare performance to a raw HTML table. And then complain if the raw HTML is still slower than Delphi on win95 because HTML tables have been around since back then :D

rtpg 2y ago

> It is something a Windows95 era PC had no problem doing in something like Delphi Builder. I would recommend you actually try this, because it's not as true as you would like to believe. I am very much pro-"make things fast" but let's not pretend that old machines didn't randomly hiccup on things all the time as well.

stoperaticless 2y ago
Well. If it was bearable then, with 2x powerful pc, it should be much better.