DEV Community: Maks

Build Collaborative Spreadsheets and Data Grids

Maks — Tue, 23 Jun 2026 10:26:49 +0000

Daily we do not start by saying:

“Let’s build Google Sheets inside our application.”

We start:

“We need an editable table.”

Then the customer asks us for one more "little" thing.

Copy and paste from Excel 📋 😊
Formulas 📐 🤔
Comments 💬 😕
Who changed what? 👀 😩
Several people editing the same data at the same time 👥 😰

And now things are getting complicated. At that point, the table is no longer just a table.

That means the grid must handle more than rendering rows and columns. It needs real-time editing, user presence, conflict resolution, validation, permissions, audit history, and safe recovery when something goes wrong.

We'll explain here how to think about collaborative spreadsheet-like applications with Data Grid.

What “collaborative” means

In many products, collaboration only means:

sharing a link;
leaving comments;
exporting a file;
sending a report to another user.

For a spreadsheet-like data grid, collaboration means something much deeper.

A collaborative grid should allow:

multiple users to work in the same grid at the same time;
real-time synchronization of edits;
user presence indicators;
visible selected cells and ranges from other users;
conflict detection when two users edit the same data;
conflict resolution policies;
pending changes and review workflows;
backend validation before final commit;
audit history for accepted changes;
rollback or restore when needed;
permissions by user, role, row, column, or cell.

A basic editable grid asks:

Can this user edit this cell?

A collaborative grid asks:

Can this user edit this cell right now, while other users may also be editing related data, without losing work, breaking formulas, or violating permissions?

That is a much harder problem.

Why collaborative spreadsheet could be hard to make?

The UI looks simple.

A user clicks a cell and changes a value:

Budget Q3 = 120,000

But a collaborative application has to understand much more:

type CollaborativeCellChange = {
  documentId: string;

  previousValue: Value;
  nextValue: Value;

  userId: string;
  clientId: string;
  operationId: string;
};

Now imagine two users edit the same cell at nearly the same time.

Anna changes the value from 120,000 to 130,000.
Mark changes the same value from 120,000 to 125,000.

How to resolve the conflict?

There is no single correct answer.

For a note field, the latest value may be fine.
For a finance field, silent overwrite is dangerous.
For a workflow status, one edit may need to be rejected.
For a locked row, neither edit should be allowed.

A real collaborative grid does not just send edits over WebSocket.

It needs a clear product model.

Conflict resolution

A conflict happens when two or more users edit the same data before the system can safely reconcile the changes.

Example:

Anna changes forecastMar from 18000 to 20000.
Mark changes the same cell from 18000 to 19000.
Both edits arrive close together.

The product must decide what to do.

Strategy 1: Manual conflict review

Manual conflict review is the safest option for serious business data.

The system keeps the local change pending and shows the user that another value already exists.

Example UX:

Conflict detected

Anna changed this cell to: 20,000
You changed it to: 19,000

Choose:
- Keep Anna's value
- Apply your value
- Open cell history

This is useful for:

finance;
resource planning;
approvals;
pricing;
inventory;
customer-facing data;
operational workflows.

Example editing configuration:

const collaborativeEditing: CollaborativeEditingConfig = {
  // ...
  conflictPolicy: 'manual'
};

You can open a custom conflict dialog from the collaborative conflict event:

grid.addEventListener('collaborativeconflict', (event: CustomEvent) => {
  const conflict = event.detail;

  openConflictDialog({
    rowId: conflict.local.rowId,
    columnId: conflict.local.prop,
    localValue: conflict.local.newValue,
    remoteValue: conflict.remoteValue,
    remoteUser: conflict.remoteUser
  });
});

Manual conflict resolution is usually the best default for high-value B2B workflows.

Strategy 2: Last write wins

The simplest model is last write wins.

The latest accepted edit becomes the final value.

Example:

const collaborativeEditing: CollaborativeEditingConfig = {
  // ...
  conflictPolicy: 'lastWriteWins'
};

This can be acceptable for:

notes;
temporary planning values;
draft-only fields;
low-risk comments;
internal scratch data.

It is usually not appropriate for:

budgets;
prices;
approved values;
inventory quantities;
workflow status;
financial records;
compliance-sensitive data.

Last write wins feels smooth, but it can silently overwrite another user’s work.

Use it deliberately.

Strategy 3: Soft warnings

Sometimes the product should not block the user.

It should warn them.

Example:

This value was changed by Anna 18 seconds ago.
Please review before saving.

This is useful for:

planning grids;
CRM updates;
content calendars;
lightweight operational data;
provisional values.

Soft warnings reduce friction while still giving users context.

Strategy 4: Locks and protected ranges

Some workflows should prevent conflicts before they happen.

Example:

This row is currently being edited by Anna.

Or:

This month is locked because Finance already approved it.

Locks are useful for:

approved periods;
billing data;
purchase orders;
stock adjustments;
workflow transitions;
high-risk rows.

A lock can be strict:

type RowLock = {
  rowId: string;
  lockedBy: string;
  expiresAt: string;
};

Or advisory:

Anna is editing this row. You can continue, but your change may require review.

For most real products, the best model is hybrid:

Data type	Recommended strategy
Notes and drafts	Last write wins
Normal business values	Soft warning or manual review
Finance, pricing, inventory	Manual review
Approved rows or closed periods	Lock
Formula cells	Protected or review-only
Workflow status	Permission-aware manual review

One global conflict strategy is rarely enough.

Presence: show who is working where

Presence makes collaboration visible.

A collaborative grid should show:

who is currently viewing the document;
who selected a cell;
who selected a range;
who is editing;
which users are idle;
when stale presence should disappear.

Example UI:

Anna is editing Forecast Mar
Mark selected B4:D8
Elena is viewing the Finance Review tab

A useful presence model:

type PresenceUser = {
  id: string;
  name: string;
  color: string;
  activity: 'viewing' | 'editing' | 'idle';

  focus?: {
    rowId: string;
    columnId: string;
  };

  range?: {
    startRowId: string;
    endRowId: string;
    startColumnId: string;
    endColumnId: string;
  };

  lastActiveAt: string;
};

Presence should be visual and temporary.

It should not be treated as authoritative business data.

Cell values are persistent.
Presence is ephemeral.

This distinction matters.

Permissions: collaboration must be safe

In collaborative spreadsheets, permissions should not stop at page-level access.

You may need:

document-level permissions;
sheet-level permissions;
row-level permissions;
column-level permissions;
cell-level permissions;
formula permissions;
export permissions;
approval permissions.

Example:

Role	Can view	Can edit	Can approve
Sales rep	Own customers	Own forecast cells	No
Sales manager	Team customers	Team forecast cells	No
Finance	All customers	Approved values and formulas	Yes
Executive	Summary view	No	No

The grid should show permissions visually.

Good patterns:

locked cells are muted;
protected columns show a lock icon;
context menu actions are hidden when unavailable;
tooltips explain why a cell is read-only;
rejected edits show clear reasons.

Bad UX:

Error: forbidden

Better UX:

This value is locked because March has already been approved by Finance.

Frontend permissions improve the user experience, but backend permissions are still mandatory.

Never trust only the browser.

Example: collaborative inventory planning grid

A collaborative inventory planning app may have rows like:

SKU;
warehouse;
current stock;
reorder point;
incoming quantity;
expected delivery;
supplier;
risk level.

Users:

warehouse operators;
procurement managers;
finance;
supplier coordinators.

Grid rules:

warehouse operators can edit stock counts;
procurement can edit reorder quantities;
finance can lock budget-sensitive fields;
supplier coordinators can comment on delivery changes;
high-risk SKUs are highlighted;
every stock adjustment is audited.

This is a good fit for a collaborative RevoGrid workflow because the interface needs spreadsheet speed, but the product needs business rules.

A generic spreadsheet can store this data.

A RevoGrid-based product can enforce the workflow.

Example: collaborative project planning grid

A project planning grid may include:

project;
task;
owner;
status;
start date;
end date;
progress;
dependency;
risk;
budget.

Users:

project managers;
resource managers;
team leads;
finance;
client viewers.

Features needed:

inline editing;
date editors;
assignee dropdowns;
status badges;
comments;
audit history;
saved views;
permissions;
export to Excel;
conflict handling;
timeline or Gantt view.

This is where RevoGrid Pro becomes interesting beyond the grid itself.

A planning product may need:

grid for structured editing;
formulas for calculations;
audit history for accountability;
Gantt for timelines;
scheduler for resource allocation;
pivot tables for reporting.

The grid becomes the center of a larger operational workflow.

What to include in a production collaborative grid

A serious collaborative spreadsheet should include the following.

Multi-user editing

Users should be able to edit the same grid at the same time.

Include:

live updates;
optimistic edits;
backend acknowledgement;
pending state;
rollback on rejection;
conflict events;
reconnect behavior.

Presence

Users should see who else is active.

Include:

user avatars or initials;
active cell;
selected range;
editing label;
stale user cleanup;
subtle visual markers.

Conflict resolution

Do not rely on one universal strategy.

Include:

manual review for critical cells;
last write wins for low-risk fields;
soft warnings for normal business edits;
locks for approved or transactional rows.

Permissions

Permissions should be visible and enforced.

Include:

read-only columns;
row locks;
cell-level edit rules;
role-based permissions;
server-side validation;
clear rejection messages.

Audit history

Every important change should be reviewable.

Include:

who changed it;
previous value;
new value;
timestamp;
source of change;
transaction grouping;
restore action;
exportable audit log.

Spreadsheet behavior

Users expect spreadsheet-like interaction.

Include:

formulas;
copy and paste;
range selection;
multi-range selection;
smart auto-fill;
validation;
merged cells where needed;
Excel export/import.

Product workflow

A collaborative grid should fit your domain.

Include:

custom cell renderers;
status badges;
approval states;
comments;
saved views;
tooltips;
context menus;
workflow actions.

Common mistakes

Mistake 1: Treating WebSocket sync as collaboration

A WebSocket moves messages.

It does not solve:

permissions;
conflicts;
validation;
audit;
rollback;
formulas;
reconnect;
transaction grouping.

Real collaboration needs a product model.

Mistake 2: Using row indexes as identity

Indexes change after sorting and filtering.

Use stable row IDs.

Mistake 3: Applying last write wins everywhere

Last write wins is convenient, but dangerous.

It is acceptable for low-risk values.
It is not acceptable for budgets, approval states, inventory, pricing, or financial records.

Mistake 4: Replacing the whole grid source after every edit

This can break:

focus;
selection;
scroll position;
plugin state;
active editors;
pending changes;
undo history.

Use targeted updates where possible.

Mistake 5: Making filters shared by default

Personal filters should stay personal.

Shared views should be explicit.

Mistake 6: Ignoring bulk operations

Paste, fill, and import are not edge cases.

They are core spreadsheet workflows.

Treat them as transactions.

Where this all fits

We build you a grid that gives you the high-performance spreadsheet-like grid surface:

virtualized rows and columns;
inline editing;
keyboard navigation;
range selection;
copy and paste workflows;
custom cell renderers;
custom editors;
column types;
filtering and sorting;
framework integrations for React, Vue, Angular, Svelte, and plain JavaScript.

The collaboration stack uses more than one package. RevoGrid Pro provides the grid-side helpers such as EventManagerPlugin and CollaborativePresencePlugin. Collaborative editing itself comes from the separate @revolist/revogrid-collaborative-editing package.

Together, they extend this foundation with advanced spreadsheet and workflow capabilities such as:

normalized edit event management for collaborative write flows;
collaborative editing through @revolist/revogrid-collaborative-editing;
collaborative presence markers for remote focus and range selection;
conflict handling;
audit trail history;
undo and redo history;
formulas;
validation;
range copy preview;
smart auto-fill;
multi-range selection;
Excel import/export;
advanced filters;
pivot tables;
Gantt and scheduler modules.

The important architectural point is simple:

DataGrid should own the grid experience.
Your application should own the business rules.

RevoGrid handles the editing surface, rendering, events, selection, custom cells, and spreadsheet-like UX.

Your application and backend handle:

authentication;
user roles;
document access;
row and column permissions;
business validation;
persistence;
audit storage;
conflict policy;
final commit or rejection.

This separation keeps the system scalable and maintainable.

Final thought

Collaborative spreadsheets are difficult because users expect them to feel simple.

They want to edit, paste, filter, calculate, comment, undo, and collaborate without thinking about the system underneath.

But the system underneath needs to handle:

simultaneous edits;
conflict resolution;
permissions;
audit history;
validation;
formulas;
real-time updates;
recovery;
large datasets;
business workflows.

The best approach is not to clone Google Sheets feature by feature.

The better approach is to build a product-specific collaborative grid.

One that feels familiar like a spreadsheet, but understands your data model, permissions, workflow, and business rules.

That is where RevoGrid fits well.

Use RevoGrid for the high-performance spreadsheet-like grid surface.

Use your backend for authority, validation, permissions, persistence, and audit.

That combination gives you a practical path to building collaborative grid experiences that users can work in all day.

JavaScript Proxy: One more way to use it I wish I’d known 3 years ago

Maks — Sun, 07 Jun 2026 19:29:52 +0000

In our everyday work, we do a lot of data shuffling.

We work with heavily loaded data grids. We have built our own RevoGrid for this matter hence market didn't offer all options we need back than. Some of our clients want to pull 400k rows and 5k columns into the UI and look at them on huge monitors.

Don’t ask me what they see there. We deliver.

For a very long time, our approach was to rely on different event management systems. Based on the event type, we would incrementally update data sources outside of the grid.

And this works.

But the problem with this approach is that you slowly end up with a lot of different events:

cell edit
range fill
autofill
copy/paste
row grouping
grouping migration
column mapping
source refresh
external updates

Trust me, a lot.

So we were growing together with these events. One more feature, one more event. One more edge case, one more handler.

But we live in the age of reactivity, so why not take one step further and make the source itself reactive?

Instead of only reacting to grid events, we can feed the grid a source wrapped with Proxy.

The idea is simple:

The grid reads from the row through the get trap.

And when the grid tries to write something back into the data source, we catch that write through the set trap.

So the grid still works with normal-looking row objects:

row.price
row.quantity
row.status

But under the hood, we now control how reads and writes actually happen.

A very simplified version looks like this:

function createRowProxy<T extends object>(
  row: T,
  onWrite: (row: T, prop: keyof T, value: unknown) => void,
): T {
  return new Proxy(row, {
    get(target, prop, receiver) {
      return Reflect.get(target, prop, receiver);
    },

    set(target, prop, value, receiver) {
      const result = Reflect.set(target, prop, value, receiver);

      onWrite(target, prop as keyof T, value);

      return result;
    },
  });
}

Then we can pass proxied rows into the grid:

const source = rawRows.map(row =>
  createRowProxy(row, (row, prop, value) => {
    console.log('changed:', row.id, prop, value);

    // mark field as dirty
    // update external store
    // queue backend sync
    // trigger validation
    // update derived state
  }),
);

grid.source = source;

Now the interesting part:

The grid/component does not need to know anything about your real store architecture.

It does not care if your data lives in:

a plain array
a Map
a normalized store
a remote cache
a local-first database
a custom reactive state layer

From the grid perspective, it just reads and writes object properties.

But from your application perspective, you now have a controlled bridge between the grid and your real data model.

For example, the grid can read:

row.quantity

But internally this can be resolved from something like:

rowsById.get(row.id).quantity

Same for writes.

The grid can do:

row.quantity = 10

And your proxy can decide what should happen next:

set(target, prop, value) {
  updateStore(target.id, prop, value);
  markDirty(target.id, prop);
  queueSave(target.id);
  return true;
}

This is where the pattern becomes useful.

You stop treating every grid event as the main data pipeline.

Instead, the row object becomes an adapter.

Events are still useful. I would not remove them completely.

You still want events for things like:

validation cancellation
editor lifecycle
analytics
permissions
before/after hooks
custom UX behavior

But for data synchronization itself, proxy-based source handling can be much cleaner.

Especially when you have many ways to change data:

direct cell editing
paste
autofill
range updates
programmatic updates
grouping changes
external source changes

Instead of writing separate synchronization logic for every path, you can centralize a big part of it at the data access level.

Of course, there are rules.

Do not create proxies inside render loops
Keep proxy identity stable
Avoid mixing too much logic in both edit events and proxy setters, otherwise you will double-handle the same update
Think carefully about performance if you are working with very large datasets.

But as a pattern, it is surprisingly practical.

For me, this changed how I think about data flow - component does not always need to own the data flow.

Sometimes it is better to give it an object that looks simple from the outside, but is smart enough inside to route reads and writes into your actual application state.

I wrote this while working on editable data-grid internals. We use this pattern in RevoGrid’s proxy source approach, but the idea itself works with any editable table/grid where you want your app state to stay in control.

Happy coding!

React Data Tables Made Simple: A Friendly Guide into Data Grids

Maks — Tue, 21 Jan 2025 21:08:28 +0000

Data tables (or so called data grids) are at the core of many modern web applications, especially when dealing with large datasets or complex interactions. React's ecosystem offers several ways to implement a data grid, but today we'll compare two approaches:

A simple, custom-built React grid.
A robust and highly performant implementation using external libraries.

Let's dive in!

Creating a Simple React Grid

Before jumping into advanced solutions, let’s start with a basic implementation of a data grid in React using mock data. This example will give you a feel for how React components, hooks, and states can work together to create a functional grid.

Code Example

import React, { useState } from "react";

// Mock data generator
const generateMockData = (count: number) => {
  return Array.from({ length: count }, (_, index) => ({
    id: index + 1,
    name: `Name ${index + 1}`,
    age: Math.floor(Math.random() * 50) + 20,
  }));
};

const SimpleGrid = () => {
  const [data] = useState(generateMockData(50));

  return (
    <table>
      <thead>
        <tr>
          <th>ID</th>
          <th>Name</th>
          <th>Age</th>
        </tr>
      </thead>
      <tbody>
        {data.map((row) => (
          <tr key={row.id}>
            <td>{row.id}</td>
            <td>{row.name}</td>
            <td>{row.age}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
};

export default SimpleGrid;

Mock Data Generator: Creates sample rows with an id, name, and age for demonstration purposes.
State Management: Uses useState to manage and render the mock data.
HTML Table: Simple and styled to display the data as a grid.

So, you have an app that manages intensive datasets and you might think it’s straightforward enough to handle on your own. After all, implementing virtual scrolling might seem like all it takes.

But what happens when your needs grow?

Suppose you want to pin a row at the top or bottom. Add a column that also needs to be pinned. And then start grouping these elements. Soon, you might find yourself needing cell focus and range selections. This is where the complexity increases significantly.

In scenarios like this, maintaining performance while adding sophisticated grid functionalities can become difficult.
That’s where 3rd party components come in.

RevoGrid for Advanced Data Grids

We decided to use RevoGrid because we genuinely believe it’s the best data grid framework out there — and yes, we built it ourselves. With RevoGrid, you get React compatibility, unmatched performance, and the ability to handle massive datasets effortlessly. We’ve poured our expertise into creating a framework that’s feature-packed, highly customizable, and optimized to deliver a seamless experience. It’s the tool we’d choose for our own projects, and we’re confident you’ll love it too.

Installation

To get started with RevoGrid, first install the library via npm:

npm install @revolist/react-datagrid

Building a simple Example

Creating a data grid with RevoGrid in React is remarkably simple and efficient. All you have to do is define your data model, and voilà!
In the example below, we define a basic table with two columns — First and Second — and provide a static data source containing two rows.

Using useMemo, we ensure that the column definitions maintain a stable reference to avoid unnecessary re-renders. Similarly, the source data is stored in state with useState.

The component then renders the grid, automatically handling the layout and performance optimizations for the provided configuration.

// App.tsx
import { RevoGrid } from "@revolist/react-datagrid";
import { useState, useMemo } from "react";

function App() {
  // note: columns & source need a "stable" reference
  // in order to prevent infinite re-renders
  const columns = useMemo(
    () => [
      {
        prop: "name",
        name: "First",
      },
      {
        prop: "details",
        name: "Second",
      },
    ],
    []
  );
  const [source] = useState([
    {
      name: "1",
      details: "Item 1",
    },
    {
      name: "2",
      details: "Item 2",
    },
  ]);
  return (
    <>
      <RevoGrid columns={columns} source={source} />
    </>
  );
}

export default App;

Try it yourself!

Building an advanced RevoGrid Example

Below is an example implementation of RevoGrid in a React application. This example highlights row selection functionality and shows how to handle large datasets efficiently.

import React, { useState, useMemo, useCallback, useEffect } from "react";
import { ColumnRegular, RevoGrid } from "@revolist/react-datagrid";

// Mock data generator
const generateFakeDataRows = (rowsNumber: number) => {
  const result = [];
  for (let j = 0; j < rowsNumber; j++) {
    result[j] = {
      id: j,
      myRow: `Row ${j}`,
    };
  }
  return result;
};

// Make an App
const App = () => {
  const [rows] = useState(generateFakeDataRows(1000));

  // Selection state management
  const [selected, setSelected] = useState<Set<number>>(new Set());
  const [allSelectedStatus, setAllSelectedStatus] = useState<number>(0);

  const selectAll = useCallback(
    (checked: boolean) => {
      setSelected(new Set(checked ? rows.map((row) => row.id) : []));
    },
    [rows]
  );

  const selectSingle = useCallback((rowId: number, checked: boolean) => {
    setSelected((prevSelected) => {
      const updatedSelected = new Set(prevSelected);
      if (checked) {
        updatedSelected.add(rowId);
      } else {
        updatedSelected.delete(rowId);
      }
      return updatedSelected;
    });
  }, []);

  useEffect(() => {
    if (selected.size === 0) {
      setAllSelectedStatus(0);
    } else if (selected.size === rows.length) {
      setAllSelectedStatus(2);
    } else {
      setAllSelectedStatus(1);
    }
  }, [selected, rows.length]);

  const columns: ColumnRegular[] = useMemo(() => {
    const status = allSelectedStatus;
    return [
      {
        prop: "myRow",
        columnTemplate: (h, v) => {
          return [
            h("input", {
              type: "checkbox",
              indeterminate: status === 1,
              checked: status > 1 || undefined,
              onChange(e: InputEvent) {
                if (e.target instanceof HTMLInputElement) {
                  selectAll(e.target.checked);
                }
              },
            }),
            "Select All",
          ];
        },
        cellTemplate: (h, { model, value, rowIndex }) => {
          return h("label", undefined, [
            h("input", {
              type: "checkbox",
              key: rowIndex,
              checked: selected.has(model.id) || undefined,
              onChange(e: React.ChangeEvent<HTMLInputElement>) {
                if (e.target instanceof HTMLInputElement) {
                  selectSingle(model.id, e.target.checked);
                }
              },
            }),
            value,
          ]);
        },
        size: 400,
      },
    ];
  }, [allSelectedStatus, selected, selectAll, selectSingle]);

  return (
    <RevoGrid
      columns={columns}
      source={rows}
      readonly
      theme="compact"
    />
  );
};

Try it yourself!

For applications requiring high-performance grids, deep customization, and an excellent user experience, RevoGrid is the perfect choice. Start building smarter, faster grids today!

Battle of the Rows: The Limits of Data Performance

Maks — Tue, 19 Nov 2024 19:41:34 +0000

Hi there! 😊

Welcome to our recently conducted series of performance benchmarks. Data grids are becoming more popular and increasingly important as they play a vital role in managing and visualizing large datasets, especially in data-intensive applications. In this article we are going to evaluate one of the most famous data grids: AG Grid, Handsontable, and RevoGrid. Our goal was to provide you with some insight into this rapidly growing field.

Benchmark Methodology

We used the following metrics for our comparisons:

Memory Usage: Measures how efficiently each grid uses memory (What could be more important in a heavily loaded app?).
Scroll FPS: Evaluates the smoothness of scrolling, using frames per second (FPS). Typically, 60 FPS is considered the standard for smooth scrolling, but actual FPS may vary depending on browser capabilities, device performance, and other environmental factors. Variations between tests can occur due to these differences in hardware and software conditions.
Time Before First Cell Loaded: How quickly a grid can render and display the first cell (or viewport) after data is loaded.

Consider experimenting with the provided sample datasets. This hands-on approach will give you a practical understanding of grid performance.

We used four different datasets of increasing size: 1,000 rows, 100,000 rows, 200,000 rows, and 400,000 rows, each containing 100 columns. The data was generated using a web worker to avoid environmental dependencies.

We ran two types of tests:

Headless Mode: Using the Playwright framework for objective, script-driven tests.
Visual Mode: Testing manually in an actual browser environment.

Our goal was to create an unbiased, basic example of each grid, generating a large dataset and assessing how they handle this load under the same conditions.

Results Overview Summary

Handsontable

The oldest among the three. It operates based on a two-dimensional array structure and relies on traditional HTML elements like <table>, <tr>, and <td>. This makes it less flexible and contributes to performance issues.

Scrolling performance was subpar compared to the others; we noticed visible flickering when scrolling quickly, especially in dark mode. This may be due to Handsontable refreshing the entire viewport on each scroll event, which is common with traditional table structures.

100,000 Rows: 1297 MB of memory
200,000 Rows: 2498.63 MB of memory
Failed Beyond 300,000 Rows: Due to memory overhead and table duplication for column freezing, Handsontable struggled beyond 300,000 rows, often leading to crashes.

AG Grid

The most widely-used grids, backed by heavy marketing efforts. It provides a solid, user-friendly experience and features smooth, native-like scrolling. However, it also showed high memory consumption, similar to Handsontable, with its memory usage growing exponentially as we increased the dataset size.

100,000 Rows: 1297 MB of memory
200,000 Rows: 2660.75 MB of memory
Failed Beyond 300,000 Rows: Like Handsontable, AG Grid began to crash the browser tab when attempting to handle 400,000 rows.

RevoGrid

The youngest grid of the three, adopts a more modern approach. It uses virtual nodes backed by StencilJS, making it highly efficient for large datasets. RevoGrid includes advanced features that rival those of AG Grid, such as native smooth scrolling and customizable cells, while also being incredibly lightweight.

200,000 Rows: Only 368.12 MB of memory
Succeeded at 400,000 Rows: Handled 400,000 rows smoothly, using only 720 MB of RAM and retaining a smooth scroll experience.

Detailed Performance Metrics

Below are the performance metrics we collected during testing:

Testing 1,000 Rows

- AG Grid:
  - Used JS Heap Size: 40.15 MB
  - Scroll FPS: 60.23
  - Time to First Cell: 8.31 ms

- Handsontable:
  - Used JS Heap Size: 37.77 MB
  - Scroll FPS: 60.62
  - Time to First Cell: 6.67 ms

- RevoGrid:
  - Used JS Heap Size: 20.69 MB
  - Scroll FPS: 60.22
  - Time to First Cell: 6.07 ms

Testing 100,000 Rows

- **AG Grid**:
  - Used JS Heap Size: 1297.00 MB
  - Scroll FPS: 60.59
  - Time to First Cell: 10.95 ms

- Handsontable:
  - Used JS Heap Size: 1297.00 MB
  - Scroll FPS: 60.85
  - Time to First Cell: 16.71 ms

- RevoGrid:
  - Used JS Heap Size: 214.58 MB
  - Scroll FPS: 61.88
  - Time to First Cell: 6.09 ms

Testing 200,000 Rows

- AG Grid:
  - Used JS Heap Size: 2660.75 MB
  - Scroll FPS: 60.10
  - Time to First Cell: 7.42 ms

- Handsontable:
  - Used JS Heap Size: 2498.63 MB
  - Scroll FPS: 59.63
  - Time to First Cell: 13.10 ms

- RevoGrid:
  - Used JS Heap Size: 368.12 MB
  - Scroll FPS: 61.02
  - Time to First Cell: 6.14 ms

Visual Representations of Performance Metrics

To better illustrate the differences in performance between the three grids, we created bar charts for each key metric:

Memory Usage Comparison: This chart shows how much memory each grid uses for different dataset sizes.

Time Before First Cell Loaded: This chart highlights the time each grid takes to render and display the first cell.

Scroll FPS Comparison: This chart visualizes the smoothness of scrolling, using frames per second as a measure.

Final thoughts

The results of our testing clearly show that RevoGrid outperforms the other grids in terms of memory efficiency, scalability, and overall performance. It effectively handles larger datasets with significantly lower memory usage while maintaining smooth scrolling and rapid load times.

AG Grid provides a solid user experience, and Handsontable has some advantages in terms of familiarity and its traditional table semantics.

If your project needs to manage vast amounts of data without sacrificing performance, RevoGrid is an excellent choice. Its lightweight, highly optimized approach ensures that you can scale without worrying about browser crashes or excessive memory use.

Interested in comparing other grids like Tanstack, MUI, Syncfusion, or ReactTable? Let us know, and we'll create a detailed review for you.

Code repo

How to get 2000+ Github stars in 2 days

Maks — Mon, 25 Jan 2021 03:08:21 +0000

Today our project https://github.com/revolist/revogrid received crossed 2700+ stars mark. And 2000 of them happened to us in the last 2 days.

I think each of us came to GitHub with some goal. Most of us bound to the idea of organic promotion. According to it a good project is enough to become famous itself. But there are too many of them and we have to live with it.

This is a very short instruction on how to get your first stars:

Solve my pain

Write a project which the world has necessary in. You can't make people love it if there is no solution to their pain;

Good a Readme.

This is the easiest part you can start with. You just have to learn from the best. I would start with https://github.com/matiassingers/awesome-readme, you can come with your own better sample;

Leave "cold stay zone"

Get your first stars. Find a channel you like: Friends, colleagues, or some channel you start with.

And here we go

The best way to launch your ship into space is to get visible by media.
Best way to get into GitHub trending. How to do that:

Timing is important. If you aiming to be visible you have to get a significant amount of start in a short period of time;
Describe your project for media: start with writing down a very simple and beautiful description. According to which even your granny can understand what it is. Follow it with a promo picture. Better have 2
Make sure you started your Twitter live and most of us like short news from each other;
Start your activity on Reddit if you aren't there yet;
Collect your channels in one place. You'll need them soon. I would suggest some, but discover your own too:
https://www.reddit.com/r/webdev
https://www.reddit.com/r/javascript
https://www.reddit.com/r/Frontend
https://www.reddit.com/r/opensource
http://www.echojs.com
https://dev.to/t/javascript
Methodically start posting to your collected channels. Also, keep answering comments. This is very important, doesn't matter how harsh they are.

There is no clear mark where your project gets trended, for us, it was 160+ stars. But there were a lot of projects with 100+ stars and a smaller amount. The good thing is you'll get a lot of feedback about your project by this moment and will see different perspectives around it.

I wish you luck and no matter what keep trying.

What are Protocol Buffers? Will they replace JSON?

Maks — Sat, 23 Jan 2021 23:42:35 +0000

https://www.codewall.co.uk/what-are-protocol-buffers-will-they-replace-json/?utm_source=CWTwitter&utm_medium=social#

Open source excel grid system with advanced performance for Vue, React, Ember, Angular, Svelte

Maks — Fri, 22 Jan 2021 04:39:14 +0000

On regular bases I’m working in development and consulting for project with complex frontend. Most of them require enormous data representation without problems for client, others require complex ui design systems.

In the end revo-grid system was born. I have created data grid system which combines best excel sheet qualities with high performance.

These are key features:

VNode based DOM almost without rerendering. I do recombination instead;
Full customization: custom cells, headers, properties, editors;
Advanced plugin system with most important plugins out of box such as sorting, filtering, exporting to excel, column based on context size;
Custom sizes for rows and columns;
Column/Row grouping;
Freezed columns/rows;
Integration with all popular frameworks: react, vue, angulat, ember, vanilla;
Multiple other useful features just to get it in use out of box.

Hope you will enjoy component. Looking for some feedback from you. Any suggestion are welcome. Thank you.

Data grid with excel like features in 2025

Maks — Thu, 01 Oct 2020 08:44:08 +0000

In our company we are facing problems with huge datasets on client side.

So far there wasn't any good solution with MIT license, we've decided to create our own (wish it would be that easy): https://rv-grid.com.

The biggest challenge was to create multiple viewport renderers which will work fast and extend easily.

Except of usual virtualization we are using VNode DOM, which updates only changed parts, but we went much farther: - We are monitoring nodes per scroll and move nodes from edges, not entire screen redraw. With this we achieved amazing performance. Now we are going to add more features and grow up.

Thank you for reading, hope to get some feedback from you guys.