Replace NVD3 with maintained charting library

[brylie]

The NVD3 charting library, while having a nice API and default charts, is no longer actively maintained. Also, the internal structure of the NVD3 library means that each chart type is treated as distinct, so the developer API may be inconsistent or lacking across different chart types.

It may prove beneficial to replace NVD3 with a charting library that:

• is actively maintained
• provides a unified (perhaps data-centric) API across chart types

Describe alternatives you've considered
Alternatively, we could step-up involvement in NVD3 stewardship, perhaps even suggesting a more holistic library design.

There are several charting libraries to compare, including some Python charting libraries that output JavaScript charts (e.g. Bokeh).

Additional context
JavaScript charting ecosystem is somewhat fragmented, with several 'half-baked' charting libraries under varying degrees of maintenance. It would be beneficial for this project to adopt a library with holistic API design and an active stewardship model.

[issue-label-bot]

Issue-Label Bot is automatically applying the label #enhancement to this issue, with a confidence of 0.86. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned to prevent stale bot from closing the issue.

[mistercrunch]

I haven't done a lot of research but eCharts is looking pretty good! Is a very important decision and we should involve the community. With the support for visualizations as plugins, you could image that eventually we could have different "plugin packs" that we'll get to choose from.

[brylie]

For what it's worth, I was refactoring some sourcecode in the Redash repository related to preparing data for Plotly APIs. The goal was to improve the maintainability of the code, by reducing cognitive load.

My main take-away, from that review process and another open source where we are using Plotly, was that the visualization APIs that require the data to be "turned inside out" in order to fit the charting library generally leads to code that is difficult to grok and maintain.

It would be worth it to compare multiple aspects of the charting libraries, including developer ergonomics. Having worked with Seaborn, I see more clearly how a data-centric API can improve developer experience and encourage maintainable code.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned to prevent stale bot from closing the issue.