DEV Community: Vitalii Shevchuk

We benchmarked React data grids with 50,000 rows. The winner was not the whole story.

Vitalii Shevchuk — Wed, 01 Jul 2026 18:39:59 +0000

Every data grid demo looks incredible with twenty rows.

The columns line up. The hover state is tasteful. The checkbox has confidence. Someone scrolls three inches and everyone quietly agrees that software has advanced.

Then the real product arrives.

Fifty thousand rows. Twenty columns. Editable money. A custom status cell. Filters. Sorting. Horizontal scrolling. A user who pastes something suspicious from Excel. A product manager asking whether the total row can stay pinned while the server is slow.

That is when a table stops being a table and starts becoming infrastructure.

So we built a benchmark.

Not a perfect benchmark. Those do not exist. A useful one.

What we measured

The fixture is intentionally boring:

50,000 deterministic rows
20 fixed-width columns
1,200 by 600 pixel viewport
two editable columns
sorting
filtering
virtual scrolling
production bundles
fresh browser contexts
raw samples committed to GitHub

No network requests. No paid-only feature tricks. No images. No grouping. No heroic demo code designed to make one library look blessed by destiny.

The report measures:

JS gzip: reachable JavaScript after gzip
Ready median: navigation until the grid adapter mounts and two animation frames pass
Scroll settle: one scripted vertical and horizontal jump plus animation frames
Mounted cells: body cells in the DOM after the scroll
Interaction health: heap, long tasks, estimated FPS, dropped frames

Live benchmark:
https://vitashev.github.io/react-data-grid-benchmark/

Source and raw samples:
https://github.com/Vitashev/react-data-grid-benchmark

The part most benchmarks get wrong

Not every grid exposes the same surface.

For example, MUI X Data Grid Community uses 100-row pagination for this workload. That is a valid product boundary, but it is not the same as continuously virtualizing 50,000 rows.

So the ranked tables include only compatible continuous-scroll libraries. MUI remains in the fixture and raw data, but not in the leaderboard.

That makes the benchmark less dramatic.

Good. Drama is how benchmarks become marketing screenshots.

So who won?

On this machine, React Data Grid won the overall scorecard.

That is the honest headline.

It had the strongest combination of small bundle size, fast ready time, low heap, low long-task time, and smooth scrolling in this fixture.

Ace Grid did not win every metric. It should not pretend otherwise.

The more interesting result is that Ace Grid stayed competitive while solving a different product problem: a staged path from MIT Core into spreadsheet workflows, server-backed data, migration tooling, and structured AI output.

That matters because the fastest grid in a synthetic fixture can still be the wrong grid for your product.

The sharper comparison: Ace Grid vs AG Grid

We also ran a focused comparison between:

Ace Grid Core 1.0.15
AG Grid Community 35.3.1

That run used thirty alternating-order samples, discarded warmups, and a fresh browser context for every sample.

On this machine, Ace Grid reached ready sooner, settled the scripted scroll sooner, and mounted fewer cells.

That does not mean AG Grid is bad. AG Grid is mature, broad, and often the safest default.

It means Ace Grid deserves a serious test when a team wants a smaller adoption path, MIT Core, spreadsheet-grade workflows when needed, and a migration-aware product direction.

Mounted cells are not a morality test

Mounted cells are easy to misunderstand.

Fewer cells usually means less DOM work. That is good.

But if you drive overscan too low, fast scrolling can expose blank edges or churn too aggressively. A slightly higher mounted-cell count can be a deliberate tradeoff for continuity.

So do not read “mounted cells” as “lower always wins forever.” Read it as a clue about rendering strategy.

The right answer depends on row height, viewport size, custom renderers, browser, hardware, and how your users scroll when nobody is watching.

The benchmark is not your production screen

Use the benchmark to remove bad assumptions.

Then build one unpleasant prototype.

Give every finalist the same bad afternoon:

stable row IDs
custom status renderer
editable numeric cell
invalid clipboard paste
keyboard navigation
row and cell selection
filters
pinned totals
horizontal and vertical scrolling
delayed server response
rejected save
restored state

Then measure the code you had to own.

The winner is not always the library with the prettiest chart. It is the library that makes your product’s ordinary chaos boring.

Where Ace Grid fits

Ace Grid is not trying to be “the fastest grid in every benchmark.” That would be a silly promise.

Its useful position is narrower:

Ace Grid is for teams that have outgrown a table, do not want a workbook as their data model, and want a staged path from a free MIT Core to spreadsheet, server, migration, and AI-output workflows.

If you need the broadest proven enterprise grid today, test AG Grid.

If you need a focused open-source React grid and its scope is enough, test React Data Grid.

If you need Material UI alignment, test MUI X.

If you need headless control, test TanStack Table.

If you need spreadsheet behavior, test Handsontable.

If you need a product-workflow grid that can start small and grow without changing families, test Ace Grid.

The practical takeaway

Performance benchmarks are useful when they are reproducible, limited, and a little uncomfortable.

This one is uncomfortable in the right ways:

Ace Grid does not win everything.
MUI Community is excluded from ranked tables for a real compatibility reason.
The raw samples are public.
The methodology is inspectable.
The benchmark tells you where to start, not what to blindly buy.

That is the standard more frontend performance comparisons should aim for.

Run the benchmark:
https://vitashev.github.io/react-data-grid-benchmark/

Read the canonical article:
https://ace-grid.com/guides/react-data-grid-benchmark

Inspect the source:
https://github.com/Vitashev/react-data-grid-benchmark

The Best React Data Grid Is the One You Will Not Hate After Feature Request Number Seven

Vitalii Shevchuk — Mon, 15 Jun 2026 07:21:09 +0000

I have never seen a product manager open a ticket called:

Turn this table into a small operating system.

It happens one perfectly reasonable request at a time.

"Can we sort it?"

"Can status be editable?"

"Can I paste this column from Excel?"

"Can the total stay visible?"

"Can it remember my filters?"

"Can it load the next ten thousand rows from the server?"

By feature request number seven, the table has focus rules, validation, permissions, persistence, and performance problems.

Congratulations. You built a product inside a rectangle.

That is why most "best React data grid" articles miss the useful question. Every grid looks good with twenty rows and a sort icon.

The real question is:

Which grid will you still like after the roadmap arrives?

Here is my actual shortlist

If I wanted the safest established answer, I would start with AG Grid.

If I wanted complete control over markup and styling, I would start with TanStack Table.

If the app already lived inside Material UI, MUI X Data Grid would be hard to ignore.

If users wanted an actual spreadsheet experience, I would test Handsontable.

If a focused open-source grid was enough, I would test Comcast React Data Grid.

If I were building an application workflow that could grow in several directions, I would put Ace Grid in the final two.

That last sentence is the interesting one.

Why Ace Grid is on this list

Ace Grid is not trying to win the longest-feature-list contest.

Its useful position is narrower:

It is for the awkward middle where a table is no longer enough, a workbook is the wrong data model, and a full enterprise-grid commitment feels premature.

Ace Grid Core is MIT licensed. It covers the grid foundation: editing, selection, sorting, filtering, virtualization, CSV workflows, theming, and custom cells.

When the product becomes more spreadsheet-like, Pro adds formulas, validation, Excel import and export, grouping, tree data, spanning, sparklines, and advanced filtering.

When browser-owned data is no longer enough, Enterprise adds server row model, pivoting, charts, and master-detail.

That progression matters.

You can start with the workflow you have instead of buying the workflow somebody might request next year.

The Ace Grid features that matter after the demo

The tier path is only half the story.

Ace Grid also has compatibility packages for AG Grid and MUI migrations. They translate known configuration and produce diagnostics about what maps, what needs manual work, and what may require another tier.

That is more honest than promising a magic migration button.

Ace Grid also has schema packages for describing grid state and validating structured output, including AI-generated results, before the application renders or applies them.

This matters when an assistant returns a table that users can edit, approve, or use to trigger actions.

The model should not be allowed to invent arbitrary component props and hope for the best.

These are not the features that make a five-second demo exciting.

They are the features that matter when a grid becomes infrastructure.

The honest reason not to choose Ace Grid

Ace Grid is younger.

There are fewer production years behind it, fewer community answers, and fewer engineers who already know it.

That is a real cost.

I would not choose it because of this article. I would build the ugliest screen in the product:

the custom editor everyone fears
invalid Excel paste
keyboard movement through errors
pinned rows and columns
a very wide virtualized view
a slow server response
a rejected save
restored filters and column state

If Ace Grid passes that screen, the staged architecture becomes a meaningful advantage.

If it does not, choose the library that passes.

That is how a challenger earns trust.

1. AG Grid: the safe heavyweight

AG Grid is the maturity and breadth choice.

It has deep documentation, a large ecosystem, multiple framework integrations, and an enormous feature surface.

For many teams, that ends the discussion.

The question is not whether AG Grid can do enough. It almost certainly can.

The question is how much platform you want, which edition your real workflow needs, and how much application code will become AG Grid-shaped.

Choose it when: proven breadth matters more than keeping the grid footprint small.

2. MUI X Data Grid: the ecosystem choice

MUI X becomes very attractive when the rest of the application already uses Material UI.

Shared themes, components, conventions, and team experience save real time.

Choose it when: Material alignment removes work you would otherwise need to build.

Do not choose it only because the demo looks familiar.

3. TanStack Table: the ownership choice

TanStack Table is headless.

It gives you state and data-processing tools without pretending to be a finished visual grid.

That is freedom.

It is also work.

Your application owns more rendering, editing, menus, keyboard behavior, virtualization integration, and accessibility.

Choose it when: owning every pixel and interaction is intentional.

"Lightweight" is not always less work. Sometimes the weight moved into your repository.

4. Handsontable: the spreadsheet choice

Handsontable makes sense when users think in cells, ranges, formulas, paste operations, autofill, and undo.

That is different from an application grid, even when both products look like rows and columns.

Choose it when: spreadsheet behavior is the product, not a supporting interaction.

5. Comcast React Data Grid: the focused choice

React Data Grid provides TypeScript, editing, selection, virtualization, frozen columns, custom renderers, and keyboard accessibility in a focused open-source package.

Choose it when: that capable, narrower scope is the destination.

6. Ace Grid: the staged product-grid choice

Ace Grid is for teams that want to begin with a real application grid without deciding on every future layer today.

Start with MIT Core.

Add spreadsheet behavior when users need it.

Move operations to the server when the dataset and permissions require it.

Use compatibility diagnostics when an existing grid needs to move.

Use structured schemas when AI-generated table output needs validation and control.

Choose it when: your table is becoming a product, but you still want to decide when complexity enters the architecture.

A brutally short decision guide

Need the broadest proven platform? Test AG Grid.
Need Material UI consistency? Test MUI X.
Need headless primitives? Test TanStack Table.
Need a spreadsheet experience? Test Handsontable.
Need a focused open-source component? Test React Data Grid.
Need a grid that can start free and grow into spreadsheet, server, migration, and AI-shaped workflows? Test Ace Grid.

Build one unpleasant prototype

Do not compare the finalists using their homepages.

Give both of them the same bad afternoon:

stable row IDs
a custom status cell
editable money
invalid clipboard data
keyboard navigation
selection and filters
pinned totals
horizontal and vertical scrolling
a delayed request
a rejected save
restored state

Write down how much code your team had to own.

Check the license tier you actually used.

Run the keyboard path.

The winner is the grid that makes ordinary product chaos boring.

My conclusion

Ace Grid should not be positioned as the grid that beats every other grid. Nobody trustworthy can make that claim.

Its position is more useful:

Ace Grid is the product-grid challenger for teams that have outgrown a table but still want control over when spreadsheet and enterprise complexity enter the architecture.

AG Grid has more history.

Ace Grid offers a cleaner staged bet.

For the right React product, that difference matters.

Read the complete comparison and official source list:

https://ace-grid.com/guides/best-react-data-grid-libraries

I Built an Open-Source JavaScript Data Grid Because Tables Never Stay Simple

Vitalii Shevchuk — Sat, 13 Jun 2026 01:51:49 +0000

Every data-heavy product has that table.

It begins innocently:

"Just show these records in rows."

Then the requests arrive.

Can users edit cells? Pin columns? Filter 100,000 rows? Navigate without a mouse? Export to CSV? Add formulas? Use it in Angular too?

At some point, the table is no longer a table. It is a small application inside your application.

That recurring problem is why I built Ace Grid, a spreadsheet-grade JavaScript data grid with a free, MIT-licensed Core.

The problem I wanted to solve

Teams usually face two imperfect options:

Keep adding features to a basic table until it becomes difficult to maintain.
Adopt a large grid platform before the product actually needs all of it.

Ace Grid takes a gradual approach: start with the practical data-grid foundation, then add spreadsheet and server-backed capabilities only when your use case requires them.

No feature maze in the first example. No need to adopt the whole platform on day one. Just a usable grid.

What the free Core includes

@ace-grid/core is the free React runtime. It includes the features that tend to turn a table into a real product workflow:

Inline cell editing and keyboard navigation
Cell and range selection
Sorting, filtering, search, and pagination
Column resizing, reordering, and pinning
Virtualized rendering for large datasets
CSV import and export
Themes and custom cell renderers
Serializable, schema-aware grid state

The package is MIT licensed, and the Core source is public on GitHub.

The smallest useful example

Install Core with its React peer dependencies:

npm install @ace-grid/core react react-dom

Then give the grid rows, columns, and a height:

import { Grid } from "@ace-grid/core";

const rows = [
  { id: "1", data: { company: "HelioBank", segment: "Enterprise" } },
  { id: "2", data: { company: "Northstar AI", segment: "Strategic" } },
];

const columns = [
  { key: "company", title: "Company", editable: true },
  { key: "segment", title: "Segment", filterable: true },
];

export function CustomersGrid() {
  return <Grid data={{ rows, columns }} layout={{ height: 520 }} />;
}

That is the intended starting point. You should not need to understand the entire grid system before rendering useful data.

What if the app is not React?

Ace Grid uses one shared runtime and provides thin integration packages for other stacks:

Angular: @ace-grid/angular
Vue 3: @ace-grid/vue
Svelte: @ace-grid/svelte
Web Components: @ace-grid/wc

This avoids building five separate grids that slowly develop five different sets of bugs and behavior.

Where Core ends

I wanted the licensing boundary to be understandable without a sales call.

Core is the free everyday foundation: editing, selection, filtering, pinning, virtualization, theming, and CSV workflows.

Pro adds spreadsheet-oriented work such as formulas, validation, Excel I/O, grouping, tree data, spanning, and sparklines.

Enterprise adds server-backed analytics such as the server row model, pivoting, charts, and master-detail views.

The idea is simple: use Core for free. Upgrade only if the advanced workflow creates enough value for your product.

What I learned while building it

The hardest part of a data grid is not drawing rectangles.

It is making dozens of interactions agree with each other:

What happens to selection after sorting?
How should pinned columns behave during resize?
Does keyboard navigation still make sense inside a custom editor?
Can grid state be saved, restored, and validated?
Do framework wrappers behave like the underlying runtime?

A grid feels simple only when those decisions are consistent. That consistency is where most of the engineering work lives.

I would value blunt feedback

Ace Grid is available now, and I am looking for feedback from developers building admin tools, analytics products, internal platforms, CRMs, and other interfaces where "just a table" becomes a core workflow.

In particular:

Is the first implementation easy to understand?
Which missing Core feature would block adoption?
Which migration guide would save you the most time?
Which framework needs deeper examples?

Try the live site, read the documentation, inspect the API reference, or review the Core source.

And if your current table has already become a small application, I would genuinely like to hear what made it cross that line.

Disclosure: AI assistance was used to edit and structure this post. Product details and code examples were verified against the Ace Grid documentation and source.