palantir/plottable: D3 chart components that stopped shipping releases in 2021

What composition over configuration means in practice

The README states the design principle in one line: composition over configuration. Concretely it means the API's flexibility lives in choosing which Components to use and how you arrange them in Tables, rather than in setting a property on a finished chart. If you need a feature that does not exist, the README's advice is to write a new Component that implements it, so you keep the custom behaviour and still get the rest of the library.

That is the whole pitch, and it is a real difference from D3 itself. With D3 you build a chart from selections, scales and axes every time. With Plottable you assemble named pieces and inherit consistent behaviour across all of them, and you can drop down to D3 when you need to.

The pieces the README names are plots, gridlines and axes. The way it frames the library is worth repeating because it is unusual marketing copy for a charting project: it is not a charting library but rather a library of chart components, described as a D3 for Charts. Palantir built it and uses it, so the components have been exercised against a real dashboard product rather than a demo.

The install path and its D3 7 requirement

There are three documented ways in, and one requirement that catches people out. Plottable requires D3 7, spelled as d3@^7.9.0, and a browser with ES2015 support. The D3 detail matters because loading D3 from a script tag or RequireJS means using the bundled build rather than the ES module build:

npm install --save plottable

yarn add plottable

A third path is a CDN copy of the library. The catch is that the CDN link the README gives pins the major version, so it points at the 3.x line while the manifest in the repository declares 4.0.0. If you take the CDN path you are pinning yourself to the older major without the README saying so.

There are three more runtime notes that only appear in the Quick Start. CommonJS consumers need Node.js 22.12 or later to load D3's ES modules, and browser applications need a bundler with ES module support. TypeScript consumers need TypeScript 5 or later for the D3 type definitions. The Category20, Category20b and Category20c colour scales are documented as retaining their original palettes, which matters if you have stored colour values that must not shift.

Version 4.0.0 in the manifest, v3.13.0 as the newest release

Here is the first discrepancy, and it is the one that changes an adoption decision. The manifest inside the repository declares version 4.0.0. The newest GitHub release is v3.13.0, published on 2021-11-22, and the two before it are v3.12.0 from November 2021 and v3.11.0 from October 2021.

So the source tree is working on a 4.x line that has never been cut as a release, while the release feed stops in 2021. Both facts are true and they are not the same fact. Anyone installing from npm gets whatever was last published, and anyone reading the manifest sees a version number that no release page corresponds to.

The 2021 releases are small: switching to submodule imports for lodash-es, dynamic category axis tick spacing, lodash-es with a TypeScript 4.4 upgrade, support for custom font sizes. That is a maintenance cadence, not a feature cadence, and it is consistent with a library whose main consumer is the company that owns it.

The repository itself is not idle. The last push was on 2026-10-06, the default branch is develop, and the repository carries topics including octo-correct-managed, which is internal Palantir vocabulary that leaked into the topic list. Active commits plus a five year gap in releases is the pattern of an internal library that is kept alive rather than released.

A development setup that has drifted from its tooling

The README's Development section is the most revealing part of the file, because it is a set of instructions that has to be read against the manifest.

The README says to clone the repo, use the Node.js version in .nvmrc, run yarn install and yarn build, then run yarn playwright install chromium to install the browser that yarn test uses. Starting the server with yarn start brings up a development server on port 9999 that compiles the TypeScript, and you browse to the quicktests path to choose a directory of visual tests.

The manifest disagrees about how any of this is orchestrated. Its build script runs lint:tslint and build:tsc and build:webpack through npm-run-all, the start script fans out across four concurrent tasks including grunt and webpack-dev-server, and the test scripts go through grunt rather than through playwright directly. The tree carries Gruntfile.js, webpack.config.js, tslint.json, .jscsrc, .eslintrc and yarn.lock all at once.

So there are three separate linting configurations and two task runners in a repository whose README describes a yarn plus playwright workflow. The instructions are probably still correct at the level of what you type, because the underlying scripts exist, but the reasoning a new contributor would build from them does not match the scripts that would actually run. Two older build tools in that list, tslint and grunt, have been in maintenance mode for years.

Where the documentation lives and where it stops

The README says the library is developed in TypeScript and distributed in ES5 JavaScript. The Quick Start requires a browser with ES2015 support. Both statements can be true at once, because ES5 output runs on an ES2015 browser, but if you are still supporting browsers without ES2015 then the Quick Start requirement is the one that stops you, while the distribution claim is the one that suggests you will not have to. Nothing in the README reconciles the two, so treat the Quick Start requirement as the one to plan against.

The rest of the README is short by design and it says where everything else is: an examples page, a set of tutorials, and the website at plottablejs.org. For a library whose argument is that you assemble components yourself, the examples page is the real documentation, because assembly is the thing you cannot learn from a prose description.

The upgrade documentation is on the wiki rather than in the repository, with separate pages for moving to 1.0.0, for the changes between v1.16.2 and v2.0.0, and for the changes between v2.9.0 and v3.0.0. Three major version migrations are documented and none of them covers a move to 4.x, which is consistent with 4.0.0 never having shipped as a release.

The help section is notable for its tone. The README says that if Plottable is confusing, that is the project's fault rather than the user's, and it asks for an issue or a visit to the Gitter room. A library that has not published a release in five years and still invites bug reports is telling you what kind of dependency it is: one you use with an escape hatch, not one you wait on.

The cost of the composition model

The trade-off that composition buys you is the one any component library faces, and Plottable's version of it has a specific shape.

Writing a new Component is the documented escape hatch, and it is genuinely powerful: your custom chart inherits the library's axes, gridlines and layout behaviour. It is also the reason the API surface is wide, because every piece you assemble is another object with its own methods to learn. A finished charting library gives you one call and a limited set of options. Plottable gives you parts and a table layout, and the assembly work moves to you.

The second cost is that the version question is yours to manage. With an actively released library you update on the library's schedule. With Plottable you are tracking a develop branch that moves and a release feed that stopped in 2021, which means the version in your lockfile tells you less than it looks like it does.

The comparison worth drawing is against writing the chart directly in D3. Plottable wins when you have several charts that share behaviour and you want consistency without writing an axis twice. D3 wins when it is one chart, when you need a layout D3's scales give you for free, or when adding a dependency to a modern stack is the part you are trying to avoid.

Editorial conclusion

Plottable is a good fit when the chart you need is a variation on something that already exists and you want axis and gridline behaviour you do not have to write, and a poor fit when you need a new chart type or a maintained dependency. Verify two things before committing: whether the version on npm matches what you need, since the manifest says 4.0.0 while the newest GitHub release is v3.13.0 from 2021-11-22, and whether the D3 7 peer requirement is satisfied by your own build. The examples page and the tutorials are the documentation worth reading, because the README deliberately keeps itself short.

Frequently asked questions

Official sources

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