Announcing Bokeh 0.2: interactive web plotting for Python
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
Hi everyone, I'm excited to announce the v0.2 release of Bokeh, an interactive web plotting library for Python. The long-term vision for Bokeh is to provide rich interactivity, using the full power of Javascript and Canvas, to Python users who don't need to write any JS or learn the DOM. The full blog post announcement is here: http://continuum.io/blog/bokeh02 The project website (with interactive gallery) is at: http://bokeh.pydata.org And the Git repo is: https://github.com/ContinuumIO/bokeh Cheers, Peter
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/23/13 6:00 PM, Peter Wang wrote:
This looks really cool. I was checking out how easy it would be to embed in the Sage Cell Server [1]. I briefly looked at the code, and it appears that the IPython notebook mode does not use nodejs, redis, gevent, etc.? Is that right? Thanks, Jason [1] https://sagecell.sagemath.org
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
On Thu, Oct 24, 2013 at 6:36 AM, Jason Grout <jason-sage@creativetrax.com>wrote:
You actually should not need nodejs, redis, and gevent if you just want to embed the full source code of bokeh.js into the IPython notebook itself. Also, the data will be baked into the DOM as javascript variables. You will still have interactivity *within* plots inside a single Notebook, but they will not drive events back to the server side. Also, if your data is large, then the notebook will also get pretty big. (We will be working on more efficient encodings in a future release.) -Peter
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/24/13 9:47 AM, Peter Wang wrote:
It would be really cool if you could hook into the new IPython comm infrastructure to push events back to the server in IPython (this is not quite merged yet, but probably ready for experimentation like this). The comm infrastructure basically opens up a communication channel between objects on the server and the browser. Messages get sent over the normal IPython channels. The server and browser objects just use either send() or an on_message() handler. See https://github.com/ipython/ipython/pull/4195 Here's a very simple example of the Comm implementation working with matplotlib images in the Sage Cell server (which is built on top of the IPython infrastructure): http://sagecell.sagemath.org/?q=fyjgmk (I'd love to see a bokeh version of this sort of thing :). FYI, here is the javascript code we use for the above example: https://github.com/sagemath/sagecell/blob/master/static/compute_server.js#L7... and the python code is at https://github.com/sagemath/sagecell/blob/master/graphics.py#L399 Thanks, Jason
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
On Thu, Oct 24, 2013 at 10:11 AM, Jason Grout <jason-sage@creativetrax.com>wrote:
Yeah, I think we should definitely look into integrating with this mechanism for when we are embedded in a Notebook. However, we always want the underlying infrastructure to be independent of IPython Notebook, because we want people to be able to build analytical applications on top of these components.
This is interesting, and introducing widgets is already on the roadmap, tentatively v0.4. When running against a plot server, Bokeh plots already push selections back to the server side. (That's how the linked brushing in e.g. this example works: https://www.wakari.io/sharing/bundle/pwang/cars) Our immediate short-term priorities for 0.3 are improving the layout mechanism, incorporating large data processing into the plot server, and investigating basic interop with Matplotlib objects. -Peter
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/24/13 1:42 PM, Peter Wang wrote:
That makes a lot of sense. And looking at the code, it looks like you are cleanly separating out the session objects controlling communication from the plot machinery. That will hopefully make it much easier to have different transports for the communication.
Great to hear. Jason
![](https://secure.gravatar.com/avatar/29e46f3af9264db52317708bfba44d35.jpg?s=120&d=mm&r=g)
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 ? Thanks, Sebastian Haase On Thu, Oct 24, 2013 at 9:55 PM, Jason Grout <jason-sage@creativetrax.com> wrote:
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
Hi Sebastian, On Wed, Nov 6, 2013 at 4:55 AM, Sebastian Haase <seb.haase@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/23/13 6:00 PM, Peter Wang wrote:
The project website (with interactive gallery) is at: http://bokeh.pydata.org
Just a suggestion: could you put the source below each gallery image, like matplotlib does in their gallery? I see lots of pretty plots, but I have to go digging in github or somewhere to see how you made these plots. Since Bokeh is (at least partly) about making beautiful plots easy, showing off the source code is half of the story. Thanks, Jason -- Jason Grout
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
On Thu, Oct 24, 2013 at 7:39 AM, Jason Grout <jason-sage@creativetrax.com>wrote:
Thanks for the suggestion - we actually did have that at one point, but experienced some formatting issues and are working on addressing that today. -Peter
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/23/13 6:00 PM, Peter Wang wrote:
This looks really cool. I was checking out how easy it would be to embed in the Sage Cell Server [1]. I briefly looked at the code, and it appears that the IPython notebook mode does not use nodejs, redis, gevent, etc.? Is that right? Thanks, Jason [1] https://sagecell.sagemath.org
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
On Thu, Oct 24, 2013 at 6:36 AM, Jason Grout <jason-sage@creativetrax.com>wrote:
You actually should not need nodejs, redis, and gevent if you just want to embed the full source code of bokeh.js into the IPython notebook itself. Also, the data will be baked into the DOM as javascript variables. You will still have interactivity *within* plots inside a single Notebook, but they will not drive events back to the server side. Also, if your data is large, then the notebook will also get pretty big. (We will be working on more efficient encodings in a future release.) -Peter
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/24/13 9:47 AM, Peter Wang wrote:
It would be really cool if you could hook into the new IPython comm infrastructure to push events back to the server in IPython (this is not quite merged yet, but probably ready for experimentation like this). The comm infrastructure basically opens up a communication channel between objects on the server and the browser. Messages get sent over the normal IPython channels. The server and browser objects just use either send() or an on_message() handler. See https://github.com/ipython/ipython/pull/4195 Here's a very simple example of the Comm implementation working with matplotlib images in the Sage Cell server (which is built on top of the IPython infrastructure): http://sagecell.sagemath.org/?q=fyjgmk (I'd love to see a bokeh version of this sort of thing :). FYI, here is the javascript code we use for the above example: https://github.com/sagemath/sagecell/blob/master/static/compute_server.js#L7... and the python code is at https://github.com/sagemath/sagecell/blob/master/graphics.py#L399 Thanks, Jason
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
On Thu, Oct 24, 2013 at 10:11 AM, Jason Grout <jason-sage@creativetrax.com>wrote:
Yeah, I think we should definitely look into integrating with this mechanism for when we are embedded in a Notebook. However, we always want the underlying infrastructure to be independent of IPython Notebook, because we want people to be able to build analytical applications on top of these components.
This is interesting, and introducing widgets is already on the roadmap, tentatively v0.4. When running against a plot server, Bokeh plots already push selections back to the server side. (That's how the linked brushing in e.g. this example works: https://www.wakari.io/sharing/bundle/pwang/cars) Our immediate short-term priorities for 0.3 are improving the layout mechanism, incorporating large data processing into the plot server, and investigating basic interop with Matplotlib objects. -Peter
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/24/13 1:42 PM, Peter Wang wrote:
That makes a lot of sense. And looking at the code, it looks like you are cleanly separating out the session objects controlling communication from the plot machinery. That will hopefully make it much easier to have different transports for the communication.
Great to hear. Jason
![](https://secure.gravatar.com/avatar/29e46f3af9264db52317708bfba44d35.jpg?s=120&d=mm&r=g)
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 ? Thanks, Sebastian Haase On Thu, Oct 24, 2013 at 9:55 PM, Jason Grout <jason-sage@creativetrax.com> wrote:
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
Hi Sebastian, On Wed, Nov 6, 2013 at 4:55 AM, Sebastian Haase <seb.haase@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/51e47499500f6d24e238ae20fc712305.jpg?s=120&d=mm&r=g)
On 10/23/13 6:00 PM, Peter Wang wrote:
The project website (with interactive gallery) is at: http://bokeh.pydata.org
Just a suggestion: could you put the source below each gallery image, like matplotlib does in their gallery? I see lots of pretty plots, but I have to go digging in github or somewhere to see how you made these plots. Since Bokeh is (at least partly) about making beautiful plots easy, showing off the source code is half of the story. Thanks, Jason -- Jason Grout
![](https://secure.gravatar.com/avatar/3c2430d201fb71e935765851ec35e1db.jpg?s=120&d=mm&r=g)
On Thu, Oct 24, 2013 at 7:39 AM, Jason Grout <jason-sage@creativetrax.com>wrote:
Thanks for the suggestion - we actually did have that at one point, but experienced some formatting issues and are working on addressing that today. -Peter
participants (3)
-
Jason Grout
-
Peter Wang
-
Sebastian Haase