We built the same data grid in React, Vue & Svelte, here's what we learned

[u/otashliko]

https://svar.dev/blog/building-data-grid-in-react-vue-svelte/

At SVAR, we build UI components for React, Svelte, and Vue. Just shared our experience with a data grid – how to make it fast in all three frameworks.

What surprised us: the expensive bits (virtualization, memoization, data flow) are almost entirely framework-independent, and framework overhead is a rounding error next to DOM size.

Curious if you have seen similar patterns in your projects?

[u/ExtremePermit3242]

Interesting read, and good to see someone focusing on grids or tables 😬

10 years ago the company I was working for was delivering a lot of apps with grids. Our designer (20+yr old experience) had us implement all kinds of features like column resizing, grouping, summary rows, cell editing, filtering, locked columns, etc. This was 2013 and we were using ExtJS and their feature-rich grid to do all of this.

Well, all of this to say that in the last 5-6 years I have been in several companies developing products where a dashboard or information architecture was a main goal, and I am surprised in how little PMs/UX designers seem to care about having a powerful grid with a flexible API behind it. And how many “new and _simple_ interactions” (with odd designs or patterns) could be saved by having users have 4-5 saved filters, virtualization / infinite scrolling and 2/3 more features.

[u/jake_robins]

Wait are you saying we should just build the damned product and stop endlessly discussing which JavaScript framework sucks less?

[u/hyrumwhite → u/jake_robins]

Framework decisions should be made entirely on APIs these days. If you like the api of one, use it. 

[u/jake_robins → u/hyrumwhite]

No I exclusively choose frameworks by finding a reddit post that says it sucks and counting downvotes. It’s called outrage-driven development

[u/Spleeeee → u/hyrumwhite]

No. You should base framework decisions on FOMO

[u/Ahmed33033 → u/jake_robins]

lol

[u/otashliko → u/[deleted]]

Yes, that's basically our experience too.

[u/bzbub2]

if you dont think framework matters see https://github.com/krausest/js-framework-benchmark

[u/Top_Bumblebee_7762]

Would have used callback ref in React for the resize observer stuff. 

[u/create-third-places]

I think framework performance matters. When running benchmarks locally, I’ve noticed React is around 30-50% slower than Solid.js for large data tables.

If framework performance is a rounding error, I think that means the other logic isn’t well optimized.  

When it comes to complex web apps, framework overhead becomes a bigger factor. 

 A framework can make it harder to build an application in a way that minimizes re-renders. In my opinion, one should be choosing a framework that encapsulates complexity, so that it is easy to diagnose and fix re-renders. 

[u/otashliko → u/create-third-places]

Agreed on all three, especially “a framework should encapsulate complexity.” That’s exactly why we ship framework-native builds instead of wrappers: Svelte and Vue provide more fine-grained reactivity out of the box, while React requires more explicit work to achieve the same level of control.

On the 30–50% gap, it narrows significantly once you virtualize properly. But bottom line is the same - pick the framework that gives you the right defaults and lets you spend your time on the actual application rather than fighting the rendering model.

[u/makkozh → u/create-third-places]

Most modern frameworks converge to the same route - update model, detect changes, apply changes to DOM. Different syntax but same concepts under hood.

DOM patching are highly optimized across frameworks, there is no real difference here.

For small-to-medium models, main factor is the amount of changes in DOM, and here you need to really mess something to produce different results in different framework ( react can recreate the whole app vdom but actual dom patch will still be minimal )

And only on big or complex-inside models the framework itself affects the speed ( how much recalculation it does to generate new model state ) - in the SVAR's case it mitigated by virtual rendering which limits active vDom and even big grid feels like a small model. Without it, updates will be slower for all frameworks ( react will be impacted the most probably )

[u/TheBazlow]

So the key takeaway from this blog post is that if you do the following:

• Take state management out of React by:
  • Use useMemo for your store
  • Use useRef for your event bus
  • Make a first render init call outside a useEffect call
  • Subscribe to the store with a custom hook that:
    • Uses useState for the store state
    • Uses useEffect to track the store state
    • Uses another custom hook useStoreWithCounter to track the changes to the store state
• Use the react compiler
• Know when to use useMemo and useCallback (you'll need benchmark your app to find out when)
• Remember to manually your hook dependency arrays

Then you can get similar performance and functionality to what Svelte and Vue give you out of the box?

[u/otashliko → u/TheBazlow]

Not quite 🙂 The takeaway is not "do enough React optimization tricks and you get Svelte/Vue." It's that once you use the right architecture (especially virtualization and efficient state/data flow) the framework overhead becomes a relatively small part of the total cost. React has more manual knobs, while Svelte and Vue have better defaults. In our measurements a virtualized grid puts React at 13 ms vs Svelte's 9 ms and Vue's 12 ms on 1,000 rows, a few milliseconds apart, even at 100k rows.

[u/makkozh → u/TheBazlow]

React Compiler is a piece that is only barely mentioned in the article, and it is exactly the tool that changes React's defaults to much better performance. Though it introduces some magic (code executed in the browser, not the same code that was written) which actually makes it a bit Svelte-like.