use standard plotting implementation

[scottdraves]

replace our plotting API with a more standard one such as:

1. vega
2. chartjs
3. bokeh
4. bqplot

we would need an API adaptor to maintain code compatibility (but new code could access the new API directly of course).

[jpallas]

5. plotly.js?

How important are existing language bindings? For Scala, vega has vegas, and bokeh has bokeh-scala. It looks like the existing plotly Scala support is only for the server-based product and not for plotly.js. chartjs and bqplot don't seem to have anything for Scala.

Do any of these have native Java or Groovy support?

[benmccann]

@jpallas I know Chart.js has https://github.com/mdewilde/chart for Java support. You should be able to use it from the other JVM languages like Scala and Groovy as well.

[benmccann]

I've worked on projects in the past where having several charts on the page or having one chart with a large number of data points has had a performance impact and switching from svg to canvas made a big improvement. I'd like to suggest we look at the backend rendering used as one consideration. I've listed what I can find below

• vega - canvas or svg
• Chart.js - canvas
• bokeh - canvas
• bqplot - says canvas is on the roadmap, but it's a pretty big change, so it probably won't happen anytime in the foreseeable future
• plotly - svg. It looks like only scatter charts support webgl. Documentation for webgl support is quite sparse

[benmccann]

@scottdraves Some of the libraries suggested have Python APIs (bokeh & bqplot) while others have JavaScript APIs (vega & chart.js). Is one preferable over the other?

[scottdraves]

i think having some kind of JavaScript API is a requirement since our current plotting widget would have to call it to draw the plot, when the plot was created with a current kernel API (groovy, python, scala, etc).

[jameskoch2]

(Beaker newb here, apologies if this is off-base)

On the subject of language bindings, I've found the plotting approach in spark-notebook to be useful. They expose basically the full plotly API in its native JSON format, unencumbered by the Scala typesystem. Contrast this w/ existing BeakerX Scala plotting APIs, which attempt to model all the fine-grained details in Scala types.

(Most interesting examples start about half way down this page)

https://github.com/spark-notebook/spark-notebook/blob/ae3b20cbdb89a18c5a210746e640d0ae7238f1db/notebooks/viz/Custom%20Plotly%20Charts.snb.ipynb

vs

http://nbviewer.jupyter.org/github/twosigma/beakerx/blob/master/doc/scala/Plot.ipynb

[altavir]

It is specifics of Plotly. Since it is initially a JS library, Plotly API in any language is just a wrapper for its JSON. I don't think it will work this way for any other library, since most of them create language API first and JSON later.