Web development has changed a lot. We have LLMs, AI-assisted coding, etc. But some things remain the same: architecture and performance. ...
For further actions, you may consider blocking this person and/or reporting abuse
I think you can proudly claim to be the only person writing about React and its components whose articles I actually read. 😄 You know my preference for backend — or, to put it more honestly, my almost formal aversion to frontend, which I tend to see as a necessary evil.
But your articles are always interesting, and this benchmark in particular caught my attention. Not so much because of React itself, but because of your approach: you didn't just take the vendor's benchmark results at face value. You actually ran the tests yourself, under much more realistic conditions, and looked at whether the relative advantage survived rather than obsessing over reproducing the exact numbers. That's much more meaningful to me than another set of vendor-approved charts.
And then there's your sense of humor. The image of “three Formula 1 cars, an old Volkswagen Passat, a Fiat Panda, and someone who had decided to compete on foot” absolutely made my day. 😂
Another very enjoyable read, as usual!
Thank you so much, Pascal! 😄 Exactly, I never take anything at face value. I need to check it for myself! And honestly, that's part of the fun: give me an excuse to experiment with some technology and I'll happily disappear down that rabbit hole. 😂
And yes, that's pretty much what it looked like with those grids. The three slower ones really were the Passat, the Fiat Panda, and the person running on foot. 😂 Well, people are clearly using them, so maybe they're perfectly fast enough for what they need. Who knows!
Really glad you enjoyed it!
Haha, I can definitely relate to the “disappear down that rabbit hole” part. 😂
And you're absolutely right about the slower grids: benchmarks can tell you which car wins the race, but they don't necessarily tell you whether the Panda is already fast enough to get you where you need to go. 😄
I think that's actually another good lesson from your benchmark: performance numbers are useful, but context matters at least as much. And sometimes the “slow” solution is still the perfectly sensible one.
Keep disappearing down those rabbit holes — they're clearly producing good articles! 😉
Haha, I definitely have a tendency to disappear down those rabbit holes. 😂 But I have a feeling you do too, judging by how ridiculously polished and well thought-out your projects always are! 😄
Haha, guilty as charged. 😂
I suppose we both have the same problem: once something gets interesting, “just a quick experiment” has a nasty habit of turning into a full-blown rabbit hole. 😄
And I'll happily take “ridiculously polished and well thought-out” as a compliment — even if it probably says more about my inability to leave things alone than anything else. 😂
Hahaha, exactly! 😂 I have the exact same condition: “But how could I make this even better? Maybe just one more little feature?” And suddenly the “quick experiment” has become an entire project. xD
Thank you so much, Sylwia, for this valuable article.
😊
You tackled a highly important topic for developers; combining precise technical benchmarks with practical, real-world insights gives us a comprehensive view to make the right decisions, rather than just chasing abstract numbers.
🌊🧊
I wish you continued growth and success, and I look forward to reading more of your insightful work.
Thank you so much! 😊 That's exactly what I was hoping to achieve with this article: make the decision a little easier for developers by showing what these grids actually look like in practice, not just on paper. Really glad you found it useful!
(Disclosure: I work at Handsontable.)
This benchmark was fair. We ran it ourselves on the public harness before changing anything, and Handsontable 17.1.0 did exactly what the charts show.
It also gave us a to-do list. After a few weeks of performance work, we reran the same harness with our 18.1.0 build: the 500K and 1M row tests that previously failed with out-of-memory errors now run at ~30 FPS, heap usage dropped as much as 10x (1,338 MB to 126 MB on sorting 100K), and cell updates went from 6.8 to 20 FPS. At 1M rows, Handsontable had the lowest memory footprint of the grids we retested.
LyteNyte is still the fastest scroller in our reruns, ~57 FPS even at 1M rows; genuinely impressive work. Thanks for building the benchmark in the open.
Hahaha, this might be my favorite comment today. LyteNyte basically handed you a performance optimization roadmap. 😂
And I have to admin, there's clearly some really solid engineering behind that grid. I haven't seen performance like this in a long time!
Great benchmark comparisons! In our experience with financial dashboards handling fast-updating ticker grids (10k+ rows with frequent cell updates), virtualization alone isn't always the bottleneck—it's how the grid handles React reconciliation and DOM node recycling per cell.
Grids that bypass React state updates for cell-level mutations (direct DOM manipulation or offloading to canvas/WebGL) tend to maintain steady 60fps scrolling without triggering React render passes on untouched viewport nodes. Really nice to see open-source reproduction steps provided here.
Thanks! And yes, exactly! In fact, one of the grids that, as I wrote in the article, behaved like someone entering a Formula 1 race on foot 😂 didn't bypass React reconciliation at all.
That's precisely why running this benchmark with it on my machine was practically impossible and I benchmarked only the three fastest grids. With that many cell updates going through React, completing the full test would have taken forever. 😅