LyteNyte Grid: a headless React data grid split into Core and Pro

Two packages decide your feature ceiling before you write any code

LyteNyte Grid takes on one specific job: giving a React application a fast, interactive table without asking the team to build sorting, filtering, grouping, pivoting, tree views, cell editing and server-side data loading from scratch. The repository description calls it a zero-dependency React data grid of roughly 40 KB gzipped, and the README frames the audience as developers who would rather spend their time on the application than on grid internals. Two packages ship from the monorepo, and the README's feature table splits them into Core and Pro columns. The reactive foundation sits in both columns: declarative prop configuration, controlled or uncontrolled state, and the URL or external state integration. The wider set of capabilities is not presented as belonging to Core. That split is a commercial decision, not a technical one, and you make it before writing a line of grid code, because the install command and the licence both change.

The grid holds no state you have to hunt down

The central architectural claim is that LyteNyte Grid is fully stateless and prop-driven. The README describes configuration as declarative, driven by your state, and points at three sources for that state: URL parameters, server state, or any external state store you already run. There is no imperative grid object to keep in sync, because the configuration is expressed as props and the grid reflects them. The feature table names this directly under declarative prop configuration, and the reactivity documentation distinguishes a controlled mode from an uncontrolled one for each. The practical effect is that grid state can live in the URL, which makes a filtered view shareable and a back button behave the way users expect, and the same declarative shape is what the README credits with letting an AI coding agent check the code statically instead of guessing at imperative internals.

Headless and pre-styled are two ends of one API, not two libraries

Most grid choices in this category force a decision between a headless table that you style yourself and a pre-built table that ships with themes. The README states that LyteNyte Grid avoids that tradeoff, offering a headless run for full control or pre-built logic and themes when the deadline is short. The important detail for an adopter is that this is one API with two delivery modes, so a column definition or an event handler does not need rewriting when you move from a styled prototype to a fully themed product. The theming documentation is linked separately from the grid API documentation, which is a reasonable signal that visual customization is a documented surface rather than an afterthought. It also means the styling burden, if you take the headless path, sits entirely with you and with whatever CSS approach the project documents.

Installing Core or Pro, then wiring the agent skills

Both packages install from npm. The Pro package is the one to install if you want the paid feature set, and the README carries an explicit note that the package installs and runs without a licence, in which case a watermark is displayed. The Core package is the free entry point. The AI Skills installation is a separate step, done through the skills CLI against the GitHub repository, and it targets Claude Code, Windsurf, Cursor and other coding agents. Install the package first, then the skills, and expect the skills to activate on their own once they are present. The README points to a getting started guide and a step-by-step installation guide on the project site for the rest of the setup.

npm install --save @1771technologies/lytenyte-core

This pulls the free package into your React project. The paid package installs the same way, and the README notes that it runs without a licence, showing a watermark until you have one.

npm install --save @1771technologies/lytenyte-pro

The AI skills are added separately through the skills CLI, pointed at the GitHub repository.

npx skills add 1771-Technologies/lytenyte

After that, the README says the skill activates on its own when you work on a LyteNyte Grid task, with no special prompting required.

What the monorepo layout says about how the project is built

The repository root is a pnpm workspace with a pnpm-lock.yaml and a pnpm-workspace.yaml, and it holds packages/, packages-auxiliary/, demos/, documentation/, documentation-v2/, skills/ and a .changeset/ directory. The workspace root package.json is marked private with a placeholder version of 0.0.1, and its dependency list is tooling rather than grid code: react 19.2.4, react-dom 19.2.4, typescript 5.9.2, vitest 4.0.16, playwright 1.60.0, @changesets/cli 2.29.4, typedoc, eslint and prettier, plus htm and hyperscript and alasql in the development set. Browser mode testing through @vitest/browser and Playwright is configured, and typedoc is present for API docs. This is the shape of a team maintaining several packages in lockstep rather than a single library folder, which matters because adoption means consuming a published package while the source of truth is a multi-package workspace.

The performance numbers are the vendor's own

The README advertises up to 7x faster performance than competing grids, a 40 KB gzipped bundle, rendering of millions of rows, and handling of up to 10,000 updates per second, with the performance claim linking to a blog post on the vendor's own site. The same paragraph advertises 150 plus built-in grid features. None of these figures are benchmark data you can inspect, and the repository publishes no GitHub releases at all. A reader looking for independent comparison, reproducible methodology or a changelog with version numbers will not find it here. What is available is the changeset workflow: the .changeset/ directory and @changesets/cli in the root package.json indicate that version notes are accumulated and cut as changesets rather than tagged releases. The absence of GitHub releases is therefore a publishing choice, not a sign of an abandoned project, and the last push was on 2026-08-15.

Where another grid is the better call

The README draws its main comparison with other grids on mechanism rather than on feature lists, describing the wrapping layers and imperative logic that it claims other grids require. The difference in approach is concrete: LyteNyte Grid is a declarative, type-safe layer where the grid has no internal state to mirror, whereas a wrapped grid typically keeps that state behind an API you call imperatively and then keep in sync with your own. A team that already has a grid, already has styling conventions built around it, and needs nothing from the 150-feature list gains little from the migration. The same applies to a team that cannot accept a custom licence: the repository's licence is classified as Other, meaning GitHub cannot map it to a standard licence and the LICENSE file is the only place the terms appear. A commercial Pro tier, a watermark when no licence is present, and a custom licence are three separate answers to the same question about who may use this code and on what terms.

Editorial conclusion

LyteNyte Grid suits teams that want a React grid they can drive entirely from props and that ships without a UI dependency layer, and who can accept a vendor licence and a commercial tier split. It is a poor fit if you need a specific editor feature set today on the free tier, or if you need published independent benchmarks before committing. Before installing, read the LICENSE file, confirm which features the Pro tier actually unlocks for your use case, and check the repository's own changeset history for release cadence, since the project publishes no GitHub releases.

Frequently asked questions

Official sources

1. 1771-Technologies/lytenyte on GitHub
2. Issues
3. Project website
4. README