State of Chart.js & V3.0

[etimberg]

3.0 final is available

We're proud to announce that Chart.js 3.0.0 is now available. Get it with npm install --save chart.js

• Release notes
• npm
• Migration guide
• Docs
• API
• Samples

Overview

Chart.js 3.0 introduces a number of breaking changes. Chart.js 2.0 was released in April 2016. In the years since then, as Chart.js has grown in popularity and feature set, we've learned some lessons about how to better create a charting library. In order to improve performance, offer new features, and improve maintainability, it was necessary to break backwards compatibility, but we aimed to do so only when worth the benefit. Some major highlights of v3 include:

• Large performance improvements including the ability to skip data parsing and render charts in parallel via webworkers
• Additional configurability and scriptable options with better defaults
• Completely rewritten animation system
• Rewritten filler plugin with numerous bug fixes
• Documentation migrated from GitBook to Docusaurus
• API Documentation generated and verified by TypeScript
• No more CSS injection
• Tons of bug fixes
• Tree shaking

In this issue we'll maintain a list of committed, nice-to-have, and proposed features for v3. Feedback from the community will help shape the prioritization for v3.

Committed Features

• Rollup configured for ES6+ babel translation (Add babel plugin for rollup & transform code #6555)
• Remove custom (Remove undocumented "custom" feature #6605)
• Remove all deprecated code
  • Most deprecated code has been removed. However grep -ri backward src still returns a handful of results. Also need to search the code for TODOs
• Prefix all private methods with underscore
• Make ticks objects (Consider making ticks objects #5019) (or not? should we revert? see Remove ticksToTimestamps and change ticks to numbers #6791)
• Remove moment from package.json (Remove moment from dependencies #6745), move the moment adapter to an external project, and remove the rollup optional plugin
• Remove zeroLineIndex feature and replace with function based axis properties (Remove zeroLineIndex functionality #6697 & Allow functions to be specified for scale grid line options #6700)
• Change require to import, adopt ES6 classes, use const / let, etc.
• Scale cleanup
  • Change axis options from an array to an object keyed by ID (Convert axis options from arrays to objects #6773)
  • Cleanup getPixelForTick (getPixelForTick is confusing and possibly inconsistent #6715)
• Performance Improvements
  • Accept data in a format that doesn't require parsing (Consider new format for passing data in #6696)
  • Improve performance of finding hovered element (Improve hover performance #6716)
  • Split _options out of _model. Creating _model is expensive right now, since it's done for each data point. However, _options does not need to be recreated for each data point unless scriptable options are being used. Thus by just using _options directly instead of copying it into _model we would be much more performant (Rewrite animation logic #6845)
  • Reduce number of objects created (e.g. _view and _model) when animation is disabled (e.g. Performance optimizations when animations are disabled #6710).
• Make beginAtZero default be true for bar chart (Change scale.beginAtZero default to true #5939)
• Cleanup options (Rationalize option names #5233)
  • Remove element options and remove global from options namespace (Global datasets options thought #6684 Remove global from defaults #6893)
  • Standardize on using degrees for angles (Polar area: startAngle in degrees, 0 at top. #6936)
• Migrate docs from GitBook to Docusaurus (Migrate from GitBook to Docusaurus #7295)
• Support tree shaking / individual module imports (v3: consider changing export logic for esm modules #7371)
• Leverage index / value concepts
  • Remove horizontalBar and make all charts capable of being horizontal (Replace horizontalBar with indexAxis: 'y' #7144)

Proposed / Nice to Have Features

• Scale cleanups
  • Improve the scale interface & document how to use it
  • Investigate normalizing options.scales and option.scale keys for all chart types
• Performance Improvements
  • Support drawing charts without creating elements possibly as external chart type (fastline controller #6881)
  • When the tooltip and other hover actions are disabled, the chart should not be redrawn when hovering on it. This would make external custom html tooltips massively faster. Along with this, consider making the default tooltip be an external tooltip (Provide out-of-the-box HTML tooltip capability #7195 (comment))
  • Make sure the tooltip listener only applies to the chart area and not the whole canvas (Upgrade benchmark to Chart.js 3.0.0-alpha.2 leeoniya/uPlot#277 (comment))
• Cleanup options (Rationalize option names #5233)
  • Remove overrides of _resolveDataElementOptions and _resolveDatasetElementOptions (Option resolution with proxies #8374)
  • Make _dataElementOptions an array in all controllers (i.e. line and radar). (Option resolution with proxies #8374)
  • Ensure user-specified options are applied after defaults. Delete _config and have just a single object holding resolved options (Option resolution with proxies #8374)
  • Make chart.options private and immutable (user should not directly edit, but should pass in new config to merge)
  • Cleanup interactions options (Add interaction options #7922)
• Leverage index / value concepts
  • Bar / rectangle cleanup (Consider replacing rectangle x/y with index/value #6760)
• Make drawing clearer
  • Investigate making drawings sharper
• Consider renaming axis label to axis title to differentiate from the tick labels
• Improve log scale tick generation (log scale step size too large #7332)
• Bar chart
  • Allow specifying pixels between bars (e.g. 1 px space and fill the rest). Right now it can only be a percentage
• Ideas from @simonbrunel: Chart.js 3.pdf

Won't do

• Can we move hidden elements to plugin? (Remove unnecessary checks for hidden data #6255)
• Split out the time scale into it's own package
• Consider removing data from config so that we have datasets, labels, and options as first level properties. We agreed that data.datasets.data is confusing, but every chart would need to be updated if we changed this and all StackOverflow answers would be outdated

How can you help?

• Provide feedback on which issues you would like prioritized for v3
• Test out alpha & beta releases as they become available. The alpha release is quite stable though we have found a few issues. Thanks to the folks that reported them! Here's a list of known issues
• Volunteer time to help improve the project

[sebiniemann]

I would like to work on

• Change require to import

Should I do this within the current code base (may take a day for the whole projet, I could start during the upcomming weekend) aka master?

[etimberg]

@sebastianniemann I think that's the best way to do it. We've already started merging breaking changes to master. If we need to do 2.9.x hotfixes we'll do that in a separate branch.

@benmccann @kurkle thoughts?

[benmccann]

Yes, go for it! I would love that :-)

[leeoniya]

Chart.js currently struggles with hover / live value display in large datasets. Might want to also look into this.

https://github.com/leeoniya/uPlot#performance

[benmccann]

Good suggestion! I filed #6716 to discuss and track that issue

[kurkle]

Should we consider dropping IE support? It would make some new things available:
Proxy - for data change detection
Map - for array uniqueness (if we can't get rid of it). Its quite a lot faster really compared jsperfs test of it. (uPlot arrayUnique in ~25ms isntead of ~150ms)

Another thing worth exploring is ResizeObserver. That could be used, instead of current implementation, if supported.

[benmccann]

As much as I'd love to drop IE, I think there are still too many IE 11 users. The main website I'm working on right now has ~5% of traffic in IE. But it'd be great to use Proxy, Map, or ResizeObserver when they're available and fallback to the current methods for IE!

[etimberg]

I recall ResizeObserver not working entirely for div resizing last time I investigated a few years ago.

[leeoniya]

as another datapoint, our IE11 traffic for the past 2 weeks has been 2.65%, it was 5.62% for the same period last year. (usa, ecommerce, home remodeling industry).

at some point, as a lib/web author you gotta ask yourself whether maintaining IE11 compat further delays its inevitable death.