DEV Community: Maks

Best Data Grid for Python Dash in 2026

Maks — Sun, 26 Jul 2026 17:28:53 +0000

Dash gives us a way to put Python data in a browser. There is a lot of stuff we can add there, but main focus of this article is data grids, its the most common request for us.

I work on RevoGrid, so I know that option best. But RevoGrid is not the only choice, and different grids suit different projects. Here is the short, practical version of how the main Dash data grids compare in 2026.

The quick answer

Here is the practical comparison I would use before building a prototype:

Grid	Rendering approach	Editing and spreadsheet tools	Large-data approach	Licensing and status	Best fit
RevoGrid for Dash	Virtualized DOM grid	Editing, range selection, keyboard navigation, copy and paste	Virtualizes both rows and columns	MIT core, with optional Pro modules	Fast, editable data applications
Dash AG Grid	Virtualized DOM grid	Mature editing, selection and clipboard features	Multiple row models, including enterprise options	Community edition plus commercial Enterprise features	Enterprise teams needing the broadest feature set
Dash Glide Grid	Canvas	Spreadsheet-style editing, ranges, fill handle, copy and paste, undo and redo	Efficient canvas rendering	Open-source wrapper	Apps that should feel more like a spreadsheet
Dash DataTable	HTML table with virtualization options	Editing, filtering, sorting and conditional formatting	Works for moderate data; larger datasets need more care	Deprecated; planned for removal from the core Dash API in Dash 5.0	Maintaining existing Dash applications
Dash Tabulator	Virtual DOM table	Common editing and table interactions	Virtual DOM rendering	Open-source wrapper; not every Tabulator feature is exposed	Smaller projects with straightforward table needs

The grids can look similar with ten rows. The differences become clearer when you add large datasets, editing, callbacks, custom cells, or commercial licensing.

RevoGrid for Dash

RevoGrid for Dash is built for applications where the grid becomes a real workspace.

Its open-source core includes virtual scrolling, inline editing, range selection, copy and paste, sorting, filtering, pinned rows and columns, and keyboard navigation. Both rows and columns are virtualized, so the browser only renders the cells currently in view.

One detail matters a lot in Dash: when a user edits a cell, RevoGrid can send a small edit event back to Python instead of returning the entire dataset.

That keeps callbacks easier to understand and avoids moving thousands of unchanged rows after every edit.

The trade-off is that JavaScript functions cannot be passed directly through a normal Python component property. Most standard grid behavior works naturally from Dash, but deeply custom JavaScript renderers or editors need a browser-side integration.

Dash AG Grid

Dash AG Grid is the strongest alternative and probably the most familiar choice for large enterprise teams.

It has mature documentation, a large feature set, several row models, and many examples. If your company already uses AG Grid, choosing its Dash wrapper may be the simplest decision.

The main thing to check early is licensing. AG Grid Community covers many normal requirements, while features such as server-side row grouping, master/detail, tree data, and advanced aggregation belong to AG Grid Enterprise.

This is not necessarily a problem. It just means you should compare your likely future requirements—not only the features in your first prototype.

Dash Glide Grid

Dash Glide Grid uses canvas rendering and offers a smooth spreadsheet-style experience with range selection, copy and paste, a fill handle, undo and redo, and several rich cell types.

Canvas is both its strength and its main trade-off. It can render a large visual surface very efficiently, but cells are not regular DOM elements. That changes how CSS customization, browser inspection, accessibility, and embedded interactive content work.

It is worth testing if the product should feel closer to a spreadsheet than a normal web table.

Dash DataTable

Dash DataTable was the default table for many Dash applications for years. It still supports useful features such as editing, filtering, sorting, conditional formatting, and callbacks.

However, it is deprecated and is expected to leave the core Dash API in Dash 5.0. That makes it difficult to recommend for a new application.

There is no need to rewrite a stable app overnight. But if you are starting something new—or adding major table functionality—it makes sense to choose a grid with a clearer path forward.

Dash Tabulator

Dash Tabulator wraps the open-source Tabulator table.

It can be a good fit for a smaller project, especially if you already know Tabulator. The important limitation is that the Dash wrapper does not expose every feature of the underlying JavaScript library, so check its actual Python API before committing to it.

A small RevoGrid example

Install the Dash package:

pip install dash-datagrid

Then create app.py:

from dash import Dash, Input, Output, callback, html
from dash_datagrid import RevoGrid

app = Dash(__name__)

rows = [
    {"order": "A-100", "customer": "Ada", "amount": 120},
    {"order": "A-101", "customer": "Grace", "amount": 85},
    {"order": "A-102", "customer": "Linus", "amount": 210},
]

columns = [
    {"prop": "order", "name": "Order", "readonly": True},
    {"prop": "customer", "name": "Customer", "sortable": True},
    {
        "prop": "amount",
        "name": "Amount",
        "sortable": True,
        "filter": "number",
    },
]

app.layout = html.Main(
    [
        RevoGrid(
            id="orders-grid",
            source=rows,
            columns=columns,
            range=True,
            filter=True,
            resize=True,
            style={"height": 360},
        ),
        html.Pre("Edit a cell", id="edit-output"),
    ]
)


@callback(
    Output("edit-output", "children"),
    Input("orders-grid", "afteredit"),
    prevent_initial_call=True,
)
def show_edit(event):
    change = event["detail"]
    return (
        f'Row {change["rowIndex"]}: '
        f'{change["prop"]} = {change["val"]!r}'
    )


if __name__ == "__main__":
    app.run(debug=True)

Run it with:

python app.py

One easy detail to miss: give the grid an explicit height. RevoGrid fills its container, so a missing height is a common reason a new grid appears blank.

If your data is already in Pandas, the conversion is simple:

rows = dataframe.to_dict("records")

For timestamps, NumPy values, or missing values, normalizing through DataFrame.to_json() first is safer.

What I would choose

For a new, editable Dash application, I would start with RevoGrid for Dash. It gives you a capable MIT core, good spreadsheet-style interaction, virtualized rendering, and focused events for Python callbacks.

I would choose Dash AG Grid when an organization already uses AG Grid or needs specific Enterprise features. I would test Dash Glide Grid for a canvas-heavy spreadsheet experience.

For an existing Dash DataTable, I would plan a migration rather than continue building new functionality around it. And for a smaller, simpler table, Dash Tabulator may already be enough.

The best test is not a ten-row demo. Load something close to your real dataset, edit several cells, paste a range from Excel, add a callback, and see how much data travels between the browser and Python. That usually makes the right choice much more obvious.

You can try RevoGrid with:

pip install dash-datagrid

The full setup guide and API examples are in the RevoGrid Dash documentation.

MS Project Gantt Is Dead — What Now?

Maks — Fri, 10 Jul 2026 17:54:40 +0000

For years, “Gantt chart” and “Microsoft Project” were almost interchangeable.

The workflow is simple: create tasks, connect dependencies, check the critical path, assign resources, and export the plan for the next meeting.

Not anymore.....

Microsoft retired Project for the web and moved its capabilities into Microsoft Planner. Project Online is also scheduled to retire on September 30, 2026.

To be honest: the Microsoft Project desktop app is not disappearing. But Microsoft’s cloud project-management strategy is shifting to Planner—and that gives product teams a reason to reconsider where scheduling should live.

The Gantt is moving into the product

Multiple of our customers still ask the same questions:

When should work start and finish?
Which task is blocking another?
What happens if a task slips?
Which deadline is at risk?
Who is overallocated?

And they expect those answers inside the software they already use: an ERP, construction platform, manufacturing system, product-roadmap tool, logistics application, or internal operations dashboard.

For these products, sending users to a separate planning tool creates friction and splits the source of truth. The better option may be to embed planning directly into the application.

A real Gantt is more than task bars?

Drawing a colored bar on a timeline is easy. Building a schedule users can trust is much harder.

If Task B depends on Task A, the system needs to calculate what happens when Task A moves. If a task can only start after a permit date, the constraint must be respected. If a resource is assigned to two tasks at once, the system should report the conflict—or resolve it predictably.

A serious scheduling component therefore needs more than drag and drop. At minimum, look for:

task hierarchy and summary rows;
milestones;
dependencies with lead and lag;
working calendars and holidays;
constraints and deadlines;
manual and automatic scheduling;
resource allocation;
critical path and slack;
clear diagnostics when rules conflict.

The last point matters. Silent date changes quickly destroy trust. Users need to understand not only that a task moved, but why it moved.

Don’t lose the table

Our business applications do not start as Gantt charts. They start as tables.

Those contain custom columns, editors, validation, permissions, filters, keyboard workflows, status badges, and business-specific data. We could just use another model and component to build Gantt but....

A better approach is simple:

Keep the table. Add scheduling intelligence and a timeline on top.

That is the idea behind RevoGrid Gantt. The existing data grid handles the table experience—rendering, virtualization, editing, selection, and keyboard interaction. The Gantt layer adds task bars, dependencies, calendars, resources, baselines, critical path, and scheduling rules.

Users can work with familiar rows and columns while gaining a visual project plan. Developers keep control of their data model instead of rebuilding the workflow around a standalone project-management tool.

What should you do now?

Before choosing a replacement for Microsoft Project, start with your actual workflow:

List the scheduling concepts your users depend on: tasks, dependencies, calendars, resources, baselines, constraints, actuals, and custom fields.
Decide where the source of truth should live—your backend, an ERP, Dataverse, or another system.
Preserve the existing table experience, including editors, validation, permissions, and keyboard behavior.
Treat scheduling conflicts as part of the product UX, not as hidden engine errors.
Introduce complexity gradually: tasks first, then dependencies, calendars, critical path, and resource planning.

The Gantt is not dead. The silo is.

Microsoft Project shaped how a generation thinks about project scheduling. But the future of Gantt is not limited to standalone planning software.

Some teams will move to Planner. Others will choose a complete Gantt suite. And many product teams will bring scheduling into the applications where work already happens.

For that last group, the direction is clear:

Keep the grid. Add the timeline. Preserve the context.

Further reading: Microsoft’s Planner FAQ and the RevoGrid Gantt documentation.

Make AI Agents See Your Website

Maks — Fri, 10 Jul 2026 17:25:20 +0000

AI coding agents are now part of the developer workflow. Whether we like that shift or hate it, users ask Codex, Cursor, Claude Code, GitHub Copilot, and other tools to install packages, wire examples, migrate code, and explain APIs. For JavaScript data grids, that often means asking an agent to build columns, editors, filters, Pivot views, or Gantt timelines.

We ran into the obvious problem: the docs were written for people. A person can use the sidebar, search, breadcrumbs, examples, and product context. An agent often starts with a URL and a vague instruction. If it cannot find the right entry point quickly, it guesses.

There are several ways to make a site easier for agents to use: an MCP server for live retrieval, skill bundles for structured on-demand context, and llms.txt as a public discovery layer.

That is where llms.txt helps. It is a public, text-first entry point that tells AI agents where the important documentation lives: installation guides, API reference, examples, migration notes, troubleshooting, full text exports, and any richer machine-readable bundles.

The goal is not to “optimize for bots” at the expense of people. The goal is to make sure that when a user asks an agent to build with RevoGrid, the agent can find the same source material a careful developer would read first.

Is `llms.txt` Actually Used?

llms.txt began as a proposal, published by Answer.AI co-founder Jeremy Howard in September 2024.

There is meaningful adoption among major developer platforms:

OpenAI publishes an llms.txt index with Markdown versions of its API documentation and a combined llms-full.txt export.
Anthropic publishes an llms.txt index for its developer documentation.
Cloudflare documents its AI-consumability strategy and publishes both per-product and site-wide llms.txt and llms-full.txt files.
Stripe and Vercel expose public documentation indexes in the same format.
Mintlify automatically generates llms.txt and llms-full.txt for documentation sites hosted on its platform.

What `llms.txt` Is For

Use it to answer these questions quickly:

What is this product or library?
Where are the most important getting started docs?
Where is the API reference?
Where are examples, migration notes, and troubleshooting pages?
Is there a full text export or machine-readable bundle?
Is there an MCP server or agent-specific package?

Example shape:

# Product Documentation

## Primary Docs

- [Installation](https://rv-grid.com/guide/installation): Install and configure the package.
- [API Reference](https://rv-grid.com/guide/api/revoGrid): Public TypeScript API.
- [Migration Guide](https://rv-grid.com/guide/migration): Upgrade notes.

How to Add `llms.txt` to a Documentation Site

Choose the canonical site origin, for example https://rv-grid.com.
Generate a Markdown index at /llms.txt.
Link to the highest-signal docs first.
Include the full docs corpus if you publish one.
Include agent-specific formats such as .skill bundles or MCP instructions.
Link to it from your human-facing AI or agent documentation, and optionally include it in your sitemap.
Make sure auth middleware allows public access.
Regenerate it whenever docs change.

For most docs sites, llms.txt can be generated from the same content collection, sidebar, or route manifest that powers the website. That is important. If the AI-facing docs drift from the real docs, agents will confidently produce stale answers.

What to Include in `llms.txt`

installation and package names;
framework-specific setup for React, Vue, Angular, Svelte, or plain JavaScript;
API reference and TypeScript types;
examples and live demos;

If your product has paid, enterprise, or advanced modules, say so directly. Agents need to know whether a feature is core, Pro, Enterprise, experimental, or deprecated. Ambiguity here turns into broken code later.

Split Documentation Skill

For large docs, a split skill is usually better than asking an agent to read one giant file. The RevoGrid skill gives agents a SKILL.md index and one reference file per docs page.

This structure is no longer limited to one agent. Anthropic introduced Agent Skills as folders containing instructions, scripts, and resources, and later released the format as an open standard. OpenAI's Codex documentation also recommends a SKILL.md file with optional references/, scripts/, and assets/ directories. Both describe progressive disclosure: the agent sees a small description first and loads the full skill or individual references only when the task needs them. The format and current ecosystem are documented at Agent Skills.

This is the best format when:

the docs are large;
pages have similar headings;
the agent needs exact page-level context;
examples need surrounding explanation;
users work in tools that support skill-style uploads or local reference folders.

Better for Large Docs: Split Reference Files

For coding agents, the better structure is closer to how a human reads docs:

product-docs/
├── SKILL.md
└── references/
    ├── getting-started/
    │   └── installation.md
    ├── api-reference/
    │   └── grid.md
    └── guides/
        └── migration.md

SKILL.md is the index and operating guide. It explains when to use the docs and links to focused reference files. This mirrors the progressive-disclosure model documented by both OpenAI and the Agent Skills specification: advertise a small amount of metadata, then load detailed instructions and references only when relevant.

Each file under references/ should represent one real documentation page. The agent can read the index, choose two or three relevant files, and avoid loading a massive corpus into context.

This improves answer quality because the model sees complete local context for the page it selected: title, URL, description, source path, examples, and surrounding explanation. It also makes failures easier to debug because you can see which reference file the agent used.

Recommended Reference File Format

Each split reference file should be self-contained:

# Page Title

URL: https://rv-grid.com/guide/page/
Source: src/content/docs/guide/page.mdx
Description: Short page summary.

Page content starts here...

Keep the original code examples. Remove interactive-only wrappers that do not help in text form. If your docs use MDX components, unwrap or remove them carefully so the remaining Markdown still reads naturally.

Why Write About This Publicly

This is not only for bots. Developers are already trying to understand how their docs should work with agents, and there is not much practical writing from teams that have actually wired this into a docs pipeline.

That is the reason to write about it. Not because another SEO page needs to exist, but because someone else will hit the same problem: they publish a full text export, point an agent at it, and still get an answer that misses the important part.

The useful searches are real:

“How do I make my docs work with AI agents?”
“What should be in llms.txt?”
“Why is llms-full.txt ignored by coding agents?”
“How do I package documentation as a skill?”
“How should API docs be structured for Cursor, Codex, or Claude Code?”

The page should answer those questions directly. If it does that, search visibility is a side effect of being useful, not the whole point.

Mistakes we made

Making `llms.txt` Too Large

If llms.txt becomes another full corpus, it stops being useful as an index. Keep it short and link out.

Relying Only on `llms-full.txt`

A full export is helpful, but it is not enough for large docs. Agents often grep it and miss important context.

Splitting Without an Index

Reference files need a good SKILL.md or manifest. Without an index, the agent still has to guess which file to open.

Publishing Stale AI Docs

Do not write a separate AI manual by hand unless you can maintain it. Generate from the same docs source whenever possible.

Treating `llms.txt` as `robots.txt`

llms.txt provides content and navigation; it does not grant or deny crawler access. Keep using robots.txt and the documented controls for each crawler when access policy matters.

Promising an AI Ranking Boost

There is no reliable evidence that llms.txt alone improves AI citations or search visibility. The Ahrefs study, critical field reports, and practitioner discussion on Reddit all show why the claim remains disputed. Measure requests in server logs and evaluate agent answers against real tasks instead of assuming an effect.

A Practical Checklist

Keep llms.txt short and navigational.
Keep llms-full.txt as a full fallback.
Add split reference files for large documentation sets.
Add MCP support when your users work in tools that can retrieve live context.
Include canonical URLs in every generated page.
Preserve code fences exactly.
Use stable slugs and deterministic output.
Make the files public and easy to fetch.
Mention the machine-readable docs from your human docs.
Regenerate AI docs from the same source as the website.
Test whether agents can answer representative questions with the published files.
Monitor server logs separately for ordinary pages, Markdown pages, and llms.txt.
Keep crawler access policy in robots.txt, not llms.txt.

Sources and Further Reading

Specifications and First-Party Guidance

llms.txt proposal — the original purpose, suggested Markdown structure, and examples.
OpenAI API documentation index — a live first-party llms.txt implementation with Markdown page links and a full export.
Cloudflare: AI consumability — a detailed implementation covering indexes, full exports, per-page Markdown, and token efficiency.
Mintlify: llms.txt — automatic generation, discovery headers, authentication behavior, and file structure.
Anthropic: Equipping agents with Agent Skills — the motivation and architecture behind reusable skill folders.
OpenAI: Build skills — Codex skill structure, progressive disclosure, installation locations, and authoring practices.
Agent Skills open specification — the portable SKILL.md format and validation rules.
Anthropic: Writing effective tools for agents — guidance on tool descriptions, agent-friendly documentation, response design, and evaluation.

Adoption, Analysis, and Debate

Anthropic's public llms.txt, Stripe's public llms.txt, and Vercel's public llms.txt — examples from widely used developer platforms.
llms.txt Hub: Anthropic — a third-party directory view that makes the Anthropic implementation easier to inspect and discover.
Ahrefs: What Is llms.txt, and Should You Care About It? — adoption and request data plus a skeptical assessment of SEO claims.
Kai Spriestersbach: “The llms.txt is dead. More precisely: a dud.” — a forceful counterargument based on observed bot requests.
Reddit r/SEO practitioner discussion — community experiences and the continuing disagreement about measurable AI visibility benefits.

Final Thought

The goal is not to feed the model more text. The goal is to help the agent choose the right text.

For a small project, llms.txt plus clean Markdown pages may be enough. For larger libraries, frameworks, and enterprise components, add levels: a short index, a full fallback corpus, split reference files, and MCP for live retrieval.

That is the model we use for RevoGrid: make the docs easy for humans to browse and easy for AI agents to discover, select, and read. The fact that major platforms publish llms.txt and formally support Skills gives this approach credibility; honest measurement and multiple retrieval paths keep it grounded.

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.

DEV Community: Maks

Best Data Grid for Python Dash in 2026

The quick answer

RevoGrid for Dash

Dash AG Grid

Dash Glide Grid

Dash DataTable

Dash Tabulator

A small RevoGrid example

What I would choose

MS Project Gantt Is Dead — What Now?

The Gantt is moving into the product

A real Gantt is more than task bars?

Don’t lose the table

What should you do now?

The Gantt is not dead. The silo is.

Make AI Agents See Your Website

Is llms.txt Actually Used?

What llms.txt Is For

How to Add llms.txt to a Documentation Site

What to Include in llms.txt

Split Documentation Skill

Better for Large Docs: Split Reference Files

Recommended Reference File Format

Why Write About This Publicly

Mistakes we made

Making llms.txt Too Large

Relying Only on llms-full.txt

Splitting Without an Index

Publishing Stale AI Docs

Treating llms.txt as robots.txt

Promising an AI Ranking Boost

A Practical Checklist

Sources and Further Reading

Specifications and First-Party Guidance

Adoption, Analysis, and Debate

Final Thought

Build Collaborative Spreadsheets and Data Grids

What “collaborative” means

Why collaborative spreadsheet could be hard to make?

Conflict resolution

Strategy 1: Manual conflict review

Strategy 2: Last write wins

Strategy 3: Soft warnings

Strategy 4: Locks and protected ranges

Presence: show who is working where

Permissions: collaboration must be safe

Example: collaborative inventory planning grid

Example: collaborative project planning grid

What to include in a production collaborative grid

Multi-user editing

Presence

Conflict resolution

Permissions

Audit history

Spreadsheet behavior

Product workflow

Common mistakes

Mistake 1: Treating WebSocket sync as collaboration

Mistake 2: Using row indexes as identity

Mistake 3: Applying last write wins everywhere

Mistake 4: Replacing the whole grid source after every edit

Mistake 5: Making filters shared by default

Mistake 6: Ignoring bulk operations

Where this all fits

Final thought

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

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

Creating a Simple React Grid

RevoGrid for Advanced Data Grids

Installation

Building a simple Example

Building an advanced RevoGrid Example

Battle of the Rows: The Limits of Data Performance

Handsontable

AG Grid

RevoGrid

How to get 2000+ Github stars in 2 days

Solve my pain

Good a Readme.

Is `llms.txt` Actually Used?

What `llms.txt` Is For

How to Add `llms.txt` to a Documentation Site

What to Include in `llms.txt`

Making `llms.txt` Too Large

Relying Only on `llms-full.txt`

Treating `llms.txt` as `robots.txt`