Frappe DataTable: Interactive JavaScript Grid with Inline Editing

Why Frappe DataTable Exists

Frappe DataTable addresses a specific front-end problem: replacing SlickGrid in the Frappe codebase while retaining the grid behavior required by business applications. The README identifies SlickGrid as unmaintained and its interface as dated. It also says other grid options either lacked the required features or were closed source. The resulting project targets developers who need a browser table that goes beyond static presentation but do not want to retain a jQuery dependency.

The library is aimed at application screens containing editable records rather than publication tables. Its cell model supports inline editing, custom formatters, mouse selection, cell copying, and keyboard movement. Columns can be reordered, resized, sorted, hidden, removed, and supplemented with actions. Rows add selection, tree organization, and inline filters. These features make it relevant to administrative interfaces, record browsers, settings panels, and other screens where a user changes values directly in a grid.

The README says the project was originally built for ERPNext, but the package is presented as a general-purpose web library. The npm package is named `frappe-datatable`, while the GitHub repository is `frappe/datatable`. No React, Vue, or other framework adapter is documented in the README, so the stated scope is a JavaScript library rather than a documented component for a particular UI framework.

Rendering Cells, Columns, and Rows

Based on the README and repository layout, the public API starts with a `DataTable` constructor attached to a selector. The caller supplies column definitions and row data. In the shortest documented example, each column is a string and each data row is an array whose values follow the column order. This gives the component a direct mapping between table fields and rendered cells without requiring HTML templates for the initial table.

The library separates interaction concerns across cells, columns, and rows. Cell behavior includes inline editing, custom formatters, mouse selection, cell copying, and keyboard navigation. A custom cell editor is also mentioned for applications that need behavior beyond ordinary value entry. Column behavior includes structural controls such as reordering, resizing, sorting, hiding, removal, and custom actions. Row behavior covers selection, tree-structured organization, inline filters, and variable row heights.

The README states that large numbers of rows can be rendered without sacrificing performance and that dynamic row heights are handled efficiently. That claim comes from the project documentation, not from an independent test performed for this review. The repository includes Cypress files and test scripts, but the README does not document browser coverage, dataset sizes, memory limits, or measured rendering behavior. Those points would need direct verification before using the phrase "large dataset" as an architectural guarantee.

The package configuration also shows that distribution files are built with Rollup. Published entry points include `dist/frappe-datatable.cjs.js` for the CommonJS `main` field and minified browser distributions named through `unpkg` and `jsdelivr`. The package publishes both `dist` and `src`, which can help consumers inspect source code, but the README does not describe API compatibility guarantees between those paths.

Installing Frappe DataTable and Creating the First Grid

Install the published package with either Yarn or npm. The README specifically says that `sortablejs` must also be installed. It does not give a separate command for that dependency, so consumers should account for it explicitly in their project rather than assuming the package install is sufficient.

The documented install command is:

yarn add frappe-datatable
# or
npm install frappe-datatable

Use the command that matches the package manager already used by the application. After the dependency is available in the frontend build, instantiate `DataTable` with a selector, columns, and data. The following is the complete usage example given in the README:

const datatable = new DataTable('#datatable', {
  columns: [ 'First Name', 'Last Name', 'Position' ],
  data: [
    [ 'Don', 'Joe', 'Designer' ],
    [ 'Mary', 'Jane', 'Software Developer' ]
  ]
});

For a first real check, create an element matching `#datatable` in the page and load the project through the application's module or script system. The grid should render two rows with `First Name`, `Last Name`, and `Position` as its column headings. The README does not show the import statement, global setup, stylesheet import, or exact HTML wrapper needed in a standalone page. That omission matters for a quick trial: the constructor is clear, but the surrounding module initialization must come from the application or package distribution already used by the consumer.

Repository contributors can start the development server with the documented command:

yarn start

The README then directs contributors to open `index.html` in the repository root. Before committing a change, the project asks contributors to run:

yarn lint

Interactive Editing Versus Static Table Markup

Frappe DataTable's defining choice is to treat a table as an interaction surface rather than a collection of formatted cells. Inline editing places an editor within a selected cell, while keyboard navigation lets a user move among cells without repeatedly reaching for the mouse. Cell copying is included in the documented feature set, which is useful when a user needs to transfer displayed values elsewhere.

This approach differs from generating a conventional HTML table from row objects. A static table generator generally leaves interaction behavior to application code or third-party widgets. Frappe DataTable exposes behavior at the grid level, including selection and editable values. The benefit is less assembly work for applications that already fit the cell, column, and row model. The trade-off is coupling the application to a particular interaction model.

The README does not document validation behavior, dirty-state tracking, undo, paste handling, editing permissions, or how edited values are persisted. It also does not provide an example of a custom cell editor. Therefore, this library should not be selected on the assumption that inline editing includes a complete record-editing workflow. The application may still need to define validation, change detection, API submission, error display, and conflict handling. Those concerns are absent from the documented usage example.

SlickGrid, Frappe DataTable, and the Dependency Boundary

The clearest alternative named by the project is SlickGrid. According to the README, Frappe was using SlickGrid when the project began. The motivation describes that dependency as unmaintained and its interface as dated. Frappe DataTable was built to remove legacy UI components and cover features that other options either did not provide or implemented in closed-source products.

The practical difference described here is architectural and historical. SlickGrid is the prior grid used in the Frappe codebase. Frappe DataTable is a jQuery-free replacement designed around editable cells, column manipulation, row interactions, and dynamic row heights. The README does not provide a feature matrix, migration guide, compatibility table, or benchmark comparing the two libraries, so it would be unsafe to claim parity in every grid scenario.

A team that already depends on SlickGrid should examine migration cost rather than treating this project as a drop-in replacement. The repository does not document adapter APIs, plugin compatibility, server-side model differences, or a migration path. The package also requires `sortablejs`, so replacing one grid does not mean eliminating all supporting packages.

Constraints in Packaging, Documentation, and Data Loading

Several constraints are visible before a production integration begins. First, `sortablejs` is an additional runtime dependency according to the README. Second, the published package metadata points to prebuilt distribution files, while the README example does not show how the constructor is imported. A consumer therefore needs a matching bundler or script-loading setup.

The repository contains a development build based on Rollup 0.59.4 and older test tooling such as Cypress 9.2.0, Mocha 3.3.0, and Chai 3.5.0. These versions come from `package.json`. The README does not explain browser support or the compatibility implications of that build stack. It also does not establish that current applications should copy the repository's development environment unchanged. A library consumer normally installs the published package, but contributors working directly from `master` must account for the checked-in tooling.

The documentation is concise and does not describe server-side pagination, remote sorting, incremental loading, virtual scrolling, accessibility guarantees, CSS theming, internationalization, or framework bindings. That does not prove those capabilities are absent from the source. It means the README does not provide adoption guidance for them. Teams needing these features should inspect `src/` and `test/` before committing to the package.

Inline editing also creates a separate application responsibility. The grid can render and edit a value, but persistence requires a data layer. The README does not show save, cancel, validation, or error callbacks. A project that expects a spreadsheet-like editing model may find that it must build much of that behavior around the library.

Maintenance Signals and MIT License Obligations

The repository is not archived. Its last push was on 2026-10-14, and the recorded releases include `v1.21.3` on 2026-10-14, `v1.21.2` on 2026-09-23, and `v1.21.1` on 2026-09-19. These are concrete signs of recent repository activity. The project uses `semantic-release`, as shown by the package script, although the README does not explain its versioning or compatibility policy.

The license is MIT. This means the repository provides a permissive open-source license, but applications still need to observe its notice and license conditions. The MIT identifier should not be treated as a blanket guarantee about dependencies. The README requires `sortablejs`, and that package has its own distribution terms that the README does not describe.

Upgrade planning should include more than changing the package version. Because the README does not document a migration guide or breaking-change policy, teams should review release notes and source differences when moving between versions. The repository's `master` branch is the default branch, while `package.json` carries the development placeholder version `0.0.0-development`. Published package versioning appears to be handled outside that placeholder by the release tooling.

Editorial conclusion

Frappe DataTable fits developers replacing a legacy browser grid who need inline editing, keyboard navigation, column controls, and row interactions without jQuery. It is a weaker choice for teams that need fully documented theming, server-side data loading, accessibility behavior, or a complete backend integration out of the box. Before adoption, verify the required sortablejs setup, confirm that the available cell and column extensions satisfy the application, and test the intended editing workflow in the target browsers. The MIT license permits reuse and modification under its conditions, while the last push and releases show continuing repository activity as of 2026-10-14.

Frequently asked questions

Official sources

1. frappe/datatable on GitHub
2. License: MIT
3. Project website
4. README
5. Releases