[Numpy-discussion] Announcing Bokeh 0.2: interactive web plotting for Python

Peter Wang pwang at continuum.io
Thu Nov 7 00:24:53 EST 2013


Hi Sebastian,

On Wed, Nov 6, 2013 at 4:55 AM, Sebastian Haase <seb.haase at gmail.com> wrote:

> Hi,
> you projects looks really great!
> I was wondering if you are making use of any pre-existing javascript
> plotting library like flot or flotr2 ?
> And if not, what are your reasons ?


We did not use any pre-existing JS plotting library.  At the time we were
exploring our options (and I believe this still to be the case), the
plotting libraries were all architected to (1) have their plots specified
by JS code, (2) interact with mouse/keyboard via DOM events and JS
callbacks; (3) process data locally in the JS namespace.  Flot was one of
the few that actually had any support for callbacks to retrieve data from a
server, but even so, its data model was very limited.

We recognized that in order to support good interaction with a non-browser
language, we would need a JS runtime that was *designed* to sync its object
models with server-side state, which could then be produced and modified by
other languages.  (Python is the first language for Bokeh, of course, but
other languages should be pretty straightforward.)  We also wanted to
structure the interaction model at a higher level, and offer the
configuration of interactions from a non-JS language.

It's not entirely obvious from our current set of initial examples, but if
you use the "output_server()" mode of bokeh, and you grab the Plot object
via curplot(), you can modify graphical and data attributes of the plot,
and *they are reflected in realtime in the browser*.  This is independent
of whether your plot is in an output cell of an IPython notebook, or
embedded in some HTML page you wrote - the BokehJS library powering those
plots are watching for server-side model updates automagically.

Lastly, most of the JS plotting libraries that we saw took a very
traditional perspective on information visualization, i.e. they treat it as
mostly as a rendering task.  So, you pass in some configuration and it
rasters some pixels on a backend or outputs some SVG.  None of the ones I
looked at used a scene-graph approach to info viz.  Even the venerable
d3.js did not do this; it is a scripting layer over DOM (including SVG),
and its core concepts are the primitives of the underlying drawing system,
and not ones appropriate to the infovis task.  (Only recently did they add
an "axis" object, and there still is not any reification of coordinate
spaces and such AFAIK.)

The charting libraries that build on top of d3 (e.g. nvd3 and d3-chart)
exist for a reason... but they mostly just use d3 as a fancy SVG rendering
layer.  And, once again, they live purely in Javascript, leaving
server-side data and state management as an exercise to the
scientist/analyst.

FWIW, I have CCed the Bokeh discussion list, which is perhaps a more
appropriate list for further discussion on this topic.  :-)


-Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20131106/8485d51a/attachment.html>


More information about the NumPy-Discussion mailing list