Tables Bakeoff

A sibling of line-charts, built the same way. Numbers below are measured, not quoted: bundle sizes and line counts are read from bundles.json, which this build writes.

The seven contenders

What was measured

Facts only. Every column here is something this project actually measured — no ratings, no stars, no scores out of five. The judgement calls (default look, API ergonomics, documentation quality) are deliberately not on this page; see the gap note below.

• Bundle is gzipped JS + CSS, with the harness netted out. Every demo page loads the same — of shared code — the mount harness (which pulls in hyparquet to read the Parquet files) plus site.css — and that is not any library's doing. The React demos also have — of React subtracted, because it is shared between them and is a cost you may already be paying. That is why the plain <table> row reads under a kilobyte: its own code really is about twenty lines. The full page weight, with the harness included, is in bundles.json as totalKB.
• WASM is a separate column on purpose. Perspective ships a compiled-Rust engine and viewer that gzip barely compresses (~1%); adding it to a column of six JavaScript bundles, or averaging it against them, would be comparing different kinds of thing. Perspective's JavaScript is genuinely the fourth-lightest here — the WebAssembly beside it is the actual cost.
• Lines written counts non-blank, non-comment lines under src/demos/<key>/. It is a build-cost proxy, not a quality measure, and it is crude: it counts JSX markup the same as logic, so the React demos are structurally penalised against a demo that hands a config object to a constructor.
• Render and FPS are one machine's observations, taken in headless Chromium at 1400×1000 on the dev server, and are typed into this page from the build notes rather than generated. Small renders are stable to within a few per cent across runs; the plain <table>'s capped 100,000-row render varied by over 10% across eight runs on this machine, and by closer to 20% at 200,000 sampled separately — variance grows with render cost, not just harness noise. Treat every figure here as an order of magnitude, not a benchmark. The clock covers building the DOM and forcing layout — without the layout flush the plain <table> would report a fifth of its real cost. Bundle and line counts, by contrast, are read from the build at page load.
• ^a Observable Inputs does not window: it appends rows lazily as you scroll and never removes them. The 6.7 ms is the first ~60-row batch, not 500,000 rows, and scrolling to the bottom would leave all 500,000 live in the DOM with memory that never comes back down. It has no column windowing either, so all 80 columns of the wide dataset are built for every row it appends.
• ^b Tabulator's own documented height: "100%" pattern — the one its docs give for filling a container — silently zeroes its viewport measurement, so it renders every row instead of the visible ones: 62 seconds at 50,000 rows, and 500,000 effectively never. Removing that one option gives the 280 ms above. Nothing warned.
• ^c Glide's 500,000 rows render faster than its own 1,000-row card, because canvas paints a fixed viewport and the grid never touches the data. The bill is that nothing on screen is in the DOM: selecting the grid and copying yields an empty string, and find-in-page cannot match a value plainly visible. It does keep a hidden role="grid" mirror of the ~15 visible rows, so a screen reader gets the viewport — but not the other 499,985.
• ^d Perspective's large figure is dominated by moving 500,000 JavaScript objects across a worker boundary and rebuilding them as Arrow columns. The shared loader hands every library the same Array<Object>, which is fair but is Perspective's worst input format; an Arrow buffer or CSV would very likely cut it hard. Once loaded, sorting and filtering 500,000 rows happen in the worker and the UI thread never notices.
• Heap is not a column. Chrome pins performance.memory to a placeholder unless it is started with --enable-precise-memory-info, so any memory figure gathered here would have been invented. The demo pages say heap n/a for the same reason.

Quick picks

• Large datasets (50k–500k rows), speed is critical: Glide Data Grid — renders 500,000 rows in 24.6ms. Trade-off: text isn't selectable, find-in-page doesn't work, canvas-only rendering. Use when you're scrolling through data, not copying or searching it.
• General purpose, any size, any data: AG Grid Community — 35–248ms renders, 60 fps, mature API, handles sorting and filtering smoothly. The safest default if you're not sure what you need.
• Maximum customization, small datasets: TanStack Table — lightest React bundle (13 KB), renders via plain <table> so text is selectable, find-in-page works, dark mode is just CSS. Cost: you write the virtualizer and styling yourself (166 lines vs AG Grid's 62).
• One-liner, data exploration: Observable Inputs — one function call, no configuration, sorts on header click. Doesn't window rows, so memory grows as you scroll; fine for <10k rows.

What the measurements showed

• A plain <table> cannot render 500,000 rows at all. Uncapped it was abandoned after ten minutes with the tab unresponsive; the demo caps at 100,000. And the cost is layout, not string building: measured on this machine at 2.6 s at 50,000 rows, 6.9 s at 100,000, roughly 27 s at 200,000 — superlinear, because auto table layout must measure every cell in a column before it can size that column, and the larger renders swing 10–20% run to run (see the methodology note below). Building the HTML string is linear and cheap by comparison.
• The most dangerous configuration in this bake-off came from a library's own docs. Tabulator's height: "100%" turns a 40 ms render into a 62 second one at 50,000 rows, with no error, no warning, and nothing on screen to suggest anything is wrong. It is exactly the kind of thing you copy from a tutorial and never notice on a page of 200 rows.
• Canvas wins the row-count race and loses the text. Glide renders 500,000 rows in 24.6 ms because it never sees the data — it is handed a row count and a getCellContent(col, row) callback. Whether that trade is acceptable depends entirely on whether your users need to search, select or copy what they can see.
• Headless means you write the virtualizer. TanStack Table has the smallest React bundle here, and the most lines of code — 166, nearly triple AG Grid's 62. The row virtualizer, the column virtualizer, the spacer cells, the <colgroup>, the sticky header and the sort arrows are all hand-written. What you get back is an ordinary <table> of your own elements: dark mode is just CSS variables, text is selectable, and find-in-page works.
• Perspective is not a grid library and should not be picked as one. It is the only demo whose cells cannot go through the shared formatter at all — formatting lives inside the plugin, configured as Intl option bags with no callback to hand a function to and no locale field, so its dates render as 7/26/24 where every other demo shows 2024-07-26. Its columns genuinely do not match the other six. Judge it as a query interface over data too large for the main thread, which is what it is.

The four datasets

Real HM Land Registry Price Paid data, converted to Parquet and served as static files. Every library gets all four, from the same loader, as the same array of row objects.

• Small & rich — 1,000 property sales. Sixteen columns of mixed types: prices, dates, postcodes, street names, nulls. Stresses typography, alignment, number and date formatting, null rendering, text overflow.
• Wide — 80 columns. The same 1,000 sales plus 64 derived numeric columns. Stresses horizontal scrolling, column virtualization, header behaviour, column pinning.
• Medium — 50,000 rows. Where rendering every row as real DOM starts to hurt but has not yet collapsed. Stresses row virtualization quality, sort and filter responsiveness.
• Large — 500,000 rows. A full year of English and Welsh property sales, loaded on demand rather than on page load. Stresses load time, sustained scroll FPS, memory, sorting at scale.

Method

Same four datasets, same theme tokens, same shared cell formatter, same mounting harness for all seven. Each demo supplies four render functions and nothing else; the harness owns the page, the card layout, the clock and the FPS run, and empties the host between renders. The render clock awaits async work and forces layout before stopping, so a library that returns early cannot report a scheduling call as a render. The FPS run scrolls the element that actually moves — each demo marks its own internal viewport — because measuring a container that never scrolls returns a flat 60 fps for nothing.

The one exception: Perspective's cells do not pass through the shared formatter, because it exposes no per-cell hook — only Intl option bags per column. That is a finding about the library rather than a flaw in the method, but it means its columns are the one place on this site where a visible difference is not attributable to the library's rendering alone.

Considered, not included

• Handsontable — capable and popular, but not free for commercial use since v8; commercial deployment needs a paid licence. Everything here is permissive open source.
• Grid.js — unmaintained. No release since March 2024. A table library that has stopped shipping is not a choice worth recommending for new work, whatever its merits were.
• RevoGrid — genuinely virtualized and framework-agnostic, but a much smaller community than AG Grid or Tabulator and no advantage over them on any axis measured here. A reasonable addition later; not a gap in the current set.
• MUI X DataGrid — the MIT core is real, but it assumes MUI: theming runs through MUI's system rather than plain CSS tokens, so it could not be fed this site's theme the way the other seven were. Column pinning, tree data and aggregation sit in the paid Pro/Premium tiers.
• DataTables — the jQuery-era incumbent. The core is MIT, but the API and its ecosystem still assume jQuery and its headline editing features are commercial add-ons. Excluded as a legacy path rather than on quality.

Experiments

Exploratory spikes that are deliberately not part of the seven-way comparison above — different questions, not an eighth library card.

Contains HM Land Registry data © Crown copyright and database right 2026. This data is licensed under the Open Government Licence v3.0.

Add a library: copy demos/baseline.html and src/demos/baseline/main.js, export meta and four render functions, add the key to DEMOS in vite.config.js, and add a card and a row here. Bundle size and line count then appear by themselves.