Advantages of Bokeh vs competition

Hello,

I hope this is the place to ask a more general question not related to actual implementation problems.

What are the tangible advantages and disadvantages of bokeh vs its competitors (Plotly/Dash, MPL, Seaborn, etc)?

I’ve read a few blog posts, but for the most part I wasn’t able to back their statements up with my own research.

Best regards

Hi @Smallpups I’d be much more motivated to respond if you could enumerate some of the specific areas or features that are of interest to you, so that they could be commented on narrowly without speculating as to what is important to and what is not.

Hey @Bryan, thanks for the quick response.

I was thinking of the following:

  • Performance-wise, how does Bokeh compare?
  • Extensibility: Do you have experience in extending other Bokeh-esque libraries to fit your needs? Did this experience flow into the development of Bokeh?
  • Ease of getting started: Documentation, general complexity of Bokeh, …
  • Are there big technical decisions (different from other libs) that change how Bokeh works?
  • Is Bokeh trying to do something great, at the cost of something else?
  • Generally: Is Bokeh tailored to any use-cases? What is the motivation behind creating this plotting framework? Are there use-cases where you would recommend people to chase another library?
  • Also: Your personal (subjective) opinion on what makes Bokeh special and stand out.
  • Also: Your personal (subjective) opinion on key areas that Bokeh is lacking

Generally I’d be happy with an experts/bokeh maintainers personal opinion on the topic. Just a small sentence for the areas I mentioned would suffice, or just pick the points that you want to respond to (I think I enumerate quite a few)

(On a side note: I think the aspects that bokeh does great (and not so great) would make a great addition to the homepage, as well)

I one of the core maintainers as well as a co-creator of the project.

I have to say up front: There is enormous overlap between many Python vis tools, especially between web-based tools like Bokeh and Plotly. The absolute truth of the matter is that most often things simply come down to personal preference, e.g. API style, which is why I don’t personally spend too much time on these sorts of questions.

Performance-wise, how does Bokeh compare?

This covers enormous territory. Do you mean with respect to standalone (pure HTML, no server) output? Or with “apps” (backed by a server)? What are the data sizes of your use-case? Do you care about webgl capability? Are you asking about performance from the POV of the person viewing the final output, e.g. when using and interacting? Or performance for loading/rendering? Or generating static (PNG) images? Memory or CPU utilization? For what kinds of operations? Or something else entirely? Performance questions always, always come down to the actual specifics of what you are trying to do (not just here, in every programming context). I can mention a concrete things:

  • Bokeh (standalone or apps) supports limited WebGL rendering for several glyphs, this can often help accelerate use-cases with 100s of thousands of points
  • Bokeh apps use an efficient websocket protocol that is efficient for transporting large dense arrays

Extensibility: Do you have experience in extending other Bokeh-esque libraries to fit your needs? Did this experience flow into the development of Bokeh?

I don’t really understand what this is asking. I am a core dev on Bokeh and to be honest I don’t use other libraries as part of any regular work I do. I worked on other vis tools in the (somewhat distant) past before Bokeh but I don’t think there’s anything special or relevant about those experiences at this point.

Ease of getting started: Documentation, general complexity of Bokeh, …

This is very subjective. I’ve been using OSS for 25+ years and by the standard of my own personal experience with OSS docs over that time, I think the Bokeh docs are exceptional. Many people have complemented us on our docs. We have hundreds of live examples, live tutorial notebooks, a live demo site for apps, a large user guide, and a complete reference guide. But lots of people also find fault with them or think they are “terrible”. All I can say is that we are continually working to improve and expand and better organize our docs, all the time. cc @Timo

As for complexity, again this is highly subjective. Some people only want a purely declarative interface. Some people want dense one-liners that do lots of “magic”. Some people want fine-grained but consistent APIs. Other people only care about out-of-the-box integration with pandas or other tools. Perceived complexity mostly comes down to how much things line up with pre-conceived expectations or preferences. This isn’t a question someone else can answer for you. Best thing is to just look at some example code and see if it fits your mental model and/or API preferences.

Are there big technical decisions (different from other libs) that change how Bokeh works?
Is Bokeh trying to do something great, at the cost of something else?

I don’t really understand what these are asking for. Bokeh is a brower-based plotting library that makes it fundamentally different from MPL that uses host rendering, or vispy that uses GPU OpenGL rendering. Things like that immediately impose lots of trade-offs and there are certainly many more.This question is just too vague to answer. A better place to start is: What specifically do you want to accomplish? From that specific, tangible start relevant trade-offs and features can be identified and discussed.

Generally: Is Bokeh tailored to any use-cases? What is the motivation behind creating this plotting framework? Are there use-cases where you would recommend people to chase another library?

Bokeh was created in 2012 because at the time there was no interactive Python<–>Browser vis library available at all. Bokeh was created to fill that gap. Bokeh has always focused on 2d plotting. While there are things possible with custom extensions, if you need 3d plotting, there are probably better tools. If you need “mathtext” or “publication quality” static image output, then Matplotlib is still often the best go-to, but as always, the answer ultimately comes down to specifics. Also note that Bokeh received a large CZI grant last year specifically to improve those areas, and work is ongoing.

4 Likes

Thank you very much for this very detailed answer. This helps a lot and clears up pretty much every question I had.

One more thing: You mentioned WebGL rendering and I’ve followed Bokeh-development enough to notice that WebGL-support is being iteratively added to all glyphs:

What exactly is the reason that Browsers struggle with displaying image-figures containing more than 1500x1500 “pixels”? Is it the same reason that makes you get an Out-of-Memory-Error when drawing too many pixels onto an HTML-Canvas (but somewhat amplified by Bokeh-overhead)?
Will this nuisance be alleviated with WebGL support for ImageGlyphs?

Bokeh seems to be an incredible piece of software (as the showcase section demonstrates), thank you for your work

I’m not actually aware of what you are referring to specifically, is this a Bokeh question or a general browser question? If you have a spec reference or Minimal Reproducible Example then I could possibly comment more.