The method behind the numbers

Testing conditions

The Test Date column in the comparison table shows when each grid was last tested. This is the benchmark test date, not the product release date.

Coverage on the medium laptop: only the top 20 grids ranked by their results on the fast desktop PC were tested on the second computer.

Dataset sizes are 1k, 10k, 100k, 1M and 5M rows, where the scenario applies. Results depend on the selected device, browser and grid size.

If there is enough interest, we may add more test devices, possibly an iPad running Safari. Phone testing is not planned.

Measurement procedure

Each measurement starts on a newly loaded page. Short actions are repeated 10-20 times and the third-smallest rounded result is selected. Long actions are repeated approximately three times and the smallest result is selected. Values are generally rounded to two significant digits, sometimes one.

These published values are selected runs, not arithmetic means or medians. Although the original introduction calls them “average” times, its described selection procedure does not calculate an average. Best-run selection can underrepresent slower experiences.

What is compared

• Script size and data transfer reduction.
• Blank areas and smoothness during scrolling.
• Grid creation, view changes and data updates.
• Export and print operations where applicable.
• Product features and supplied license-cost estimates.

Creation time starts at grid initialization and ends when the visible area is rendered; page, script and data loading are excluded. Scrolling blankness and smoothness are manually assigned ratings from 1 (best) to 6 (worst), not measured milliseconds.

Scoring and filters

The original configuration assigns point thresholds to results. Intermediate numeric values are linearly interpolated; values outside a threshold range receive its boundary score. Displayed category points are rounded before being added to the total. Changing included scenarios changes the result and can change the ranking.

Negative points are possible. Price thresholds contribute zero points in the supplied configuration: pricing is shown for context, not as a performance bonus. Higher total points mean a better result under the selected criteria, not a universally better product.

From milliseconds to points: an example

For creating a grid with 1,000 rows, the supplied thresholds are 20 points at 0 ms, zero points at 200 ms and -10 points at 1,000 ms. A 100 ms result receives 10 points before category aggregation. A 600 ms result receives -5 points.

The full threshold set is available in the original scoring configuration. Reading the raw values alongside the scores helps expose the trade-offs hidden by a single total.

Status codes

Other string status values receive the lowest configured points. Unsupported, failed and not applicable are different states and should not be interpreted as the same observation.

License cost: compare like with like

The supplied Price column estimates one developer, one application and one deployment, using a perpetual license or three years of subscription and rounding to 50 USD. It aims to include the tested features. Confirm the edition, team size, renewals and deployment fees with the vendor before using a price in procurement.

Implementation and limitations

The original project states that test implementations were AI-assisted and reviewed by JavaScript developers. Only publicly documented settings and APIs are intended to be used; pre-sorting, pre-filtering and pre-grouping outside the grid are excluded from the stated testing rules.

These two test setups cannot represent all production workloads. Configuration, rendering, accessibility, server processing and product versions can change the outcome. A low benchmark score does not establish that a grid cannot meet your requirements.

Inspect detailed results → · Compare grids and official product links →