danvk/dygraphs: Canvas Time Series Charts Without a Server

What dygraphs Is For

dygraphs solves one problem: turning a table of dated values into an interactive chart in the browser. The README frames it as a library that "produces interactive, zoomable charts of time series" and lists the features that follow from that: error bands around a series, pan and zoom, values shown on mouseover, an adjustable averaging period, and compatibility with the Google Visualization API. The x axis is time. That is the whole premise, and it is why the library is small compared to general charting toolkits.

The intended user is a developer who already has the data. You pass dygraphs a CSV string, an array of arrays, or a DataTable, and it draws. There is no query layer, no data source connector, no server component. The README states plainly that it plots time series "without using an external server or Flash," so the rendering happens in the page. For an internal metrics page, a sensor log viewer, or a scientific plot embedded in a report, that is the right shape of dependency.

It is the wrong shape if you need bar charts, pie charts, treemaps or anything whose x axis is categorical. The library is built around a continuous time axis, and the README's feature list never claims otherwise.

How the Canvas Rendering Pipeline Works

The repository layout shows the split between the public entry points and the drawing code. The package exposes index.js and index.es5.js as the module entries, dist/dygraph.js as the browser build, and dist/dygraph.css as the stylesheet. The actual implementation lives under src/, with shared code in common/ and the static site under docs/ and site/. The build is driven by mksh scripts in scripts/, which is unusual enough to note: the project's npm scripts call mksh scripts/build.sh and mksh scripts/build-jsonly.sh rather than a JavaScript build tool directly.

Data flows in as one of the accepted formats and is normalized into internal series before drawing. Because the target is the HTML canvas tag, the chart is a single painted surface rather than a tree of DOM nodes per point. That is the reason dygraphs can hold long series without the per-element overhead a DOM charting library pays. The trade-off is the usual canvas trade-off: nothing inside the plot is a selectable DOM element, so text selection, per-point CSS and DOM-based accessibility tooling do not apply to the plotted area.

Interaction is handled by the library, not the browser. Pan and zoom, the mouseover legend and the averaging period are options on the chart object rather than separate widgets you wire up. According to the README, the option set is "extensive," and the options reference on dygraphs.com is where the project points for the full list.

Installing dygraphs and Drawing a First Chart

The README is explicit about installation: get dygraphs from NPM with a tarball install. It warns in bold that you should not install from the git repository, because npm fails to build the source on install from GitHub, and that the tarball from the GitHub Registry is fine.

npm install dygraphs

After that, the prebuilt JavaScript and CSS files are in node_modules/dygraphs/dist/. With a bundler such as browserify or webpack, the README shows importing the default export and constructing a chart against a container element id.

import Dygraph from 'dygraphs';
// or: const Dygraph = require('dygraphs');

const g = new Dygraph('graphdiv', data, { /* options */ });

The no-bundler path is the minimal example in the README. You include the stylesheet and script, put an empty div in the page, and pass a CSV string as the second argument. The first row is the header, the first column is the date, and the remaining columns are series. The README's example wraps construction in Dygraph.onDOMready so the container exists before the chart is created.

<link rel="stylesheet" type="text/css" href="dygraph.css" />
<script type="text/javascript" src="dygraph.js"></script>
<div id="graphdiv"></div>
<script>
  Dygraph.onDOMready(function onDOMready() {
    g = new Dygraph(
        document.getElementById("graphdiv"),
        "Date,Temperature\n" +
        "2008-05-07,75\n" +
        "2008-05-08,70\n" +
        "2008-05-09,80\n",
        { }
      );
  });
</script>

If you would rather not bundle at all, the README points to UNPKG, jsDelivr and cdnjs as places to get dygraph.js and dygraph.css. The dygraphs-es6 repository is referenced as a fully worked example of the module setup. Development on the library itself is a different story: the README lists jq, mksh, pax and python3 as Debian packages you need, then npm install and npm run build-jsonly, after which tests/demo.html opens in a browser.

The Release Gap Is the Real Risk

Look at the version history before you build on this. v2.2.0 was released on 2023-01-25 and v2.2.1 on 2023-02-16. Then nothing until v2.2.2 on 2026-07-27. The package.json in the repository still reports version 2.2.3-alpha.0, so the published line and the development line have drifted apart. The last push to the default branch was on 2026-07-29, which is recent, but a recent push and a recent release are not the same signal, and the three-and-a-half-year gap between v2.2.1 and v2.2.2 is the number that matters if you are planning an upgrade path.

The practical failure mode is not that the library stops working. It is that a bug you hit sits unfixed for years because there is no release to carry the fix. The README sends users to Stack Overflow (which it calls the preferred channel) and to Google Groups for help, not to a chat room or a triage process. There is no documented support commitment, and the README does not describe a deprecation or backport policy.

A second, non-technical constraint is stated in the README itself: dygraphs is "100% human-written" and the use of LLMs "to prepare a contribution or interact with anyone in the project or its users is not welcome." If your workflow assumes AI-assisted patches or AI-assisted issue triage, this project has told you in advance that it will not accept them.

dygraphs Compared With Plotly and Chart.js

The nearest general-purpose alternatives are Plotly.js and Chart.js, and the difference is scope rather than quality. Plotly.js ships a large catalogue of chart types, a declarative JSON figure specification, and its own hover and export machinery. Chart.js is smaller than Plotly but still covers bars, doughnuts, radar and scatter alongside line charts. Both are charting toolkits with a time axis as one option among many.

dygraphs is a time series renderer. It does not try to be a general figure grammar, and it does not ship a chart-type registry. The payoff is that a dygraphs chart is created by handing over data and an options object, with no figure schema to learn and no adapter layer between your rows and the plot. The cost is that the moment you want a bar chart next to your line chart, you are adding a second library to the page.

There is also an R side to this ecosystem. The related searches around Dygraphs in R, Dygraphs shiny and Dygraphs cran point at an R package of the same name that wraps this JavaScript library for R and Shiny users. That package is a separate project with its own release cycle; a fix landing in the JavaScript library does not automatically appear in the R wrapper. If you are working in R, check the wrapper's version against the JavaScript version before assuming behaviour.

Licence and Upgrade Cost

The repository's package.json declares "license": "MIT", and the README states that dygraphs is available under the MIT licence, included in LICENSE.txt. MIT is permissive: you can use it in closed-source products, and the obligation is essentially to keep the licence and copyright notice with the distribution. This is not legal advice, and the fact that the repository metadata carries a NOASSERTION value means an automated licence scan of the repository may not resolve it cleanly even though the package manifest and README both say MIT. If your compliance pipeline reads repository metadata rather than package.json, that mismatch is worth resolving before a release.

The upgrade cost is low in the ordinary case, because the library has no runtime dependencies to keep in step and the browser build is a single file. The cost that is not low is waiting on a fix. With releases as sparse as the 2023 to 2026 gap, a team that needs a patch has three options: pin to the last release and work around the bug, vendor a patched build, or fork. None of those is free, and the README offers no guidance on which the project prefers.

Editorial conclusion

Adopt dygraphs when you have time series data and want a canvas chart with pan, zoom and mouseover values without running a rendering server. Do not adopt it if you need a maintained release cadence, a chart type beyond time series, or a project that accepts LLM-assisted contributions, since the README states those are not welcome. Before committing, verify first that a tarball install works in your bundler, that your date strings carry the timezone you expect, and that the options you need appear in the options reference rather than only in a gallery test.

Frequently asked questions

Official sources

1. danvk/dygraphs on GitHub
2. Issues
3. Project website
4. README
5. Releases