# simple-datatables: sortable HTML tables with no jQuery, and the major version warning

> simple-datatables turns a plain HTML table into a sortable, searchable, paginated one, written in TypeScript and shipped as ES module, UMD and CSS, with no runtime dependency. Its README spends as much space on upgrade instructions as on features, which is the honest signal about a library now at version 10.3.0 with no GitHub releases published.

**fiduswriter/simple-datatables** — DataTables but in TypeScript transpiled to Vanilla JS

- Repository: https://github.com/fiduswriter/simple-datatables
- Stars: 1,609 · Forks: 280
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/fiduswriter-simple-datatables

## It transforms a table that is already in the document

simple-datatables takes an existing HTML table and upgrades it. The constructor accepts either a CSS3 selector or a reference to the element:

```javascript
import {DataTable} from "simple-datatables"

const myTable = document.querySelector("#myTable");
const dataTable = new DataTable(myTable);

// or

const dataTable = new DataTable("#myTable");
```

That is the whole integration. No data source, no schema, no render function. The library reads the rows already in the markup, builds its state from them, and rewrites the table in place with sorting, filtering, pagination, search and export controls.

This is the design's real strength and its real limit. Because the data is already in the document, the library is a natural fit for a server-rendered list. For a large dataset, every row is already in memory and in the DOM before sorting or paging occurs.

Options go in as a second parameter:

```javascript
const dataTable = new DataTable("#myTable", {
	searchable: false,
	fixedHeight: true,
	...
})
```

with labels, layout, column rendering, column visibility and column order all configurable. A `dayjs` integration exists for sorting columns holding datetime strings, which matters because native string comparison on dates is wrong across formats and time zones.

## Three build outputs, and why the CDN advice is specific

The package publishes three forms, all named in `package.json`: `main` is `dist/index.js`, `module` is `dist/module.js`, and both `jsdelivr` and `unpkg` point at `dist/umd/simple-datatables.js`. Types ship as `dist/index.d.ts`, and the stylesheet as `dist/style.css`.

So a bundler gets the ES module, a script tag gets the UMD build with the global `simpleDatatables`, and TypeScript gets declarations. The UMD name is set by the build, not by hand: `build_js_umd` runs `browserify dist/index.js --standalone simpleDatatables -o dist/umd/simple-datatables.js`, so the global follows from that flag.

The CDN instructions are the part with a warning attached, and the warning is not about security:

```html
<link href="https://cdn.jsdelivr.net/npm/simple-datatables@latest/dist/style.css" rel="stylesheet" type="text/css">
<script src="https://cdn.jsdelivr.net/npm/simple-datatables@latest" type="text/javascript"></script>
```

The README asks production sites to specify a specific major version, giving `simple-datatables@6` for the latest in the 6.x.x series and `simple-datatables@6.0` for the latest in the 6.0.x series, and says the same for `unpkg`. The reason is given plainly in the upgrading section: the upgrade from version 5 to 6 is the most complicated so far, and if you run from a CDN without pinning, you can be pushed onto a new major that requires substantial manual adjustments without changing anything in your code.

That is a dependency that changes behaviour when you do nothing. It is the single most useful thing the README says.

## The 5 to 6 upgrade is the one the README warns about

There is a dedicated upgrade guide at the documentation site, and the README's comment on it is worth quoting in full because it explains the project version history: the project started as a fork of Mobius1's Vanilla-DataTables and has since been converted to TypeScript.

The version you meet today is 10.3.0. The README does not say what changed in 6.0, 7, 8, 9 or 10, and there are no GitHub releases to find out, which means the CHANGELOG or the git history is where the detail lives. A team jumping several majors at once is working without the release notes the npm page would normally give you.

There is a sibling project for a different audience: `simple-datatables-classic`, for very old browsers such as Internet Explorer. The main package targets modern browsers, which matches the stated goal of being similar to jQuery DataTables for modern browsers without the jQuery dependency.

The DOM update strategy is also a specific decision rather than a generic one. The README credits diffDOM for faster DOM updates, and the repository links fiduswriter's diffDOM project.

## The build pipeline, and the two bundlers it uses on purpose

The scripts show a project that has kept a conventional release build rather than shipping TypeScript directly.

`build` fans out into `build_js`, `build_js_umd`, `build_css` and `build_demos`. `build_js` is `rollup -c` using `rollup.config.mjs`, `build_css` is a shell copy of `src/css/*` into `dist/`, and the demos have their own Rollup config at `rollup.demos.config.mjs` plus a CSS copy. A `postbuild_demos` step copies the UMD bundle into `docs/demos/dist/umd.js` so the hosted demos run against the build you just made.

Rollup for the module build and Browserify for the UMD bundle is an unusual pairing, and it is the kind of thing that happens when a build script accumulates history rather than being redesigned. Both outputs are correct, so the practical cost is one extra tool in the toolchain.

`prepare` is `npm run build`, which means a `npm install` in a checkout triggers a full build. Contributors are told to run `npm install` in the terminal, and that step does the build for them.

Quality gates are two commands behind one name: `lint` is `npm run lint_spelling && npm run lint_code`, with cspell over `src`, `docs` and `test` and ESLint over `src/`, `docs/demos/` and `test/`. Spelling is linted, which is a small signal about how documentation-heavy the project is. A `pre-commit` script runs `eslint --fix` on the same paths, and `pre-commit` is also registered in the `pre-commit` array. Tests are `mocha`.

## Licence, exports and what the package metadata says

The licence information differs in specificity across the repository.

The README says `LGPL` in a line of its own. `package.json` says `"license": "LGPL-3.0"`, and the LICENSE file is at the repository root. GitHub's own classifier cannot place it, which usually means the file does not match a template it recognises. If a build pipeline depends on the SPDX identifier, read the LICENSE file rather than trusting any of the three. This is not legal advice, only a note that the metadata should be checked before it is relied on.

The rest of the metadata is unremarkable and useful. The author is Johannes Wilm, and the bug tracker and homepage both point at the project. The `keywords` field lists `DataTable`, `DataTables`, `table`, `html table`, `filter` and `sort`.

The repository is not archived, the last push was on 2026-07-30, and the version in `package.json` is 10.3.0 while GitHub reports no releases. The absence of releases means the npm version is the only version marker, which is another reason to pin a range rather than track a tag.

## Conclusion

simple-datatables fits a page with a server-rendered HTML table that needs search, sort, pagination and export added in a few lines, without pulling jQuery or a component framework into the bundle. It does not fit a data grid needing virtual scrolling or server-side paging, since this is a client-side transform of markup already in the document, and the README does not describe such a mode. Verify first that your markup structure is what the library expects, then pin the CDN URL to a specific major such as `simple-datatables@6` rather than `@latest`, because a major upgrade can require manual adjustments and there are no GitHub releases to diff against.

## FAQ

### How do I install simple-datatables?

With `npm install simple-datatables --save` or `yarn add simple-datatables`. From a CDN, include both the stylesheet from `dist/style.css` and the script, and pin a specific major version for production.

### How do I initialise simple-datatables on a table?

Import the DataTable class and pass either a selector or an element: `import {DataTable} from "simple-datatables"` then `new DataTable("#myTable")`. Options go in a second parameter, for example `{searchable: false, fixedHeight: true}`.

### What data formats can simple-datatables export and import?

Export to `csv`, `txt`, `json` and `sql`, and import of `csv` and `json` data is supported, according to the feature list in the README.

### Why does the README warn against using @latest on a CDN?

Because a new major version can require substantial manual adjustments, and pinning to a series such as `simple-datatables@6` or a minor such as `@6.0` stops the change happening without any edit on your side. The 5 to 6 upgrade is called the most complicated so far.

### What licence is simple-datatables under?

The README says LGPL and `package.json` declares `LGPL-3.0`, with the LICENSE file at the repository root. GitHub's classifier does not recognise it, so read the LICENSE file if the identifier matters to your build.

### Does simple-datatables support sorting date columns correctly?

The README lists a dayjs integration for sorting columns containing datetime strings.

## Sources

- [fiduswriter/simple-datatables on GitHub](https://github.com/fiduswriter/simple-datatables)
- [Issues](https://github.com/fiduswriter/simple-datatables/issues)
- [README](https://github.com/fiduswriter/simple-datatables/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fiduswriter-simple-datatables