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.

DEV Community: Vitalii Shevchuk