How does it compare to http://nvd3.org/ ? Ember Charts seem to have much fewer chart types available, what are your further development plans?

The main difference is that because we use Ember's object model throughout our charts, it is very easy to extend them and tie them in to your application with bindings and computed properties in a generic way. For example binding the charts interval to a dropdown is just a matter of declaring a binding in you handlebars:

  {{time-series-chart
    barData=barData
    lineData=lineData
    selectedInterval=selectedInterval
  }}

One of the best parts of working with ember since 1.0 has been the way you can break apart code into components and easily drop and extend them in the application as needed. The consistent declarative API is really nice.

I hope there are more projects that come out like this and make it easier to get started building ember applications.

The current "drop in a JS library" usually involves learning and using too many JS APIs with very different styles.

I think this is our 3rd or 4th attempt at making a charting library, but the first one we are actually happy with. Good APIs for charts are surprisingly hard to get right. It was actually one of our interns (https://github.com/raykyri) who did most of the work on rewriting charts. Open source libraries are a really great match for intern projects.

THIS IS AWESOME. I was looking for something like this, and was really sad I was going to have to write something myself.... THANK YOU.

This looks nice, but I am little confused why a client side charting library needs ember as a dependency. Maybe I don't understand the intended use case....

Ember's object model is really awesome (http://emberjs.com/guides/object-model/computed-properties/) By writing our charting library with Ember we can make use of their object model while also making it super easy to use the charts inside Ember applications.

As per my example below:

  {{time-series-chart
    barData=barData
    lineData=lineData
    selectedInterval=selectedInterval
  }}

By using Ember we get all the bindings for free.

I can see the benefit there, but why make Ember a hard dependency? It seems you want the chart stuff totally decoupled, and then you could provide the above functionality as a built in wrapper or plugin. Then people who wanted to use Angular (or whatever their favorite framework is) can write their own wrappers, or you could add support for others as you saw fit.

Making a wrapper is a lot of work and you end up with an unsatisfying solution. One of my first projects was an Ember wrapper for Slickgrid, but very soon you end up hitting the walls of the abstraction, which is why we wrote Ember-table. If we use Ember throughout, we also get to use bindings and computed properties for writing the charts as well. I think in the future it might be easier to have charts depends only on specific parts of Ember and not the whole framework.

For what its worth, I've been pleased with a comparable library called Chart.js

Official: http://www.chartjs.org/ Github: https://github.com/nnnick/Chart.js

I like chartjs but a major problem for me is that it doesn't support hovering over points to see the value in a popover/tooltip. I remember seeing somebody had added it in an issue and submitted a pull request but the developer never accepted it (that might have changed, I haven't checked in a while).

I'm not at a computer to look at the code right now, but I have that working with chart.js and off the top of my head I don't remember having to tweak code. Feel free to look at the page / code: https://pl.ant.sr/

(Edit: Just re-read your comment. So, yes, its likely that they did add it.)

Thanks, I looked at your site and that's what I want. I'll have to take another look at Chartjs.

It would be nice if more of these chart libraries implemented box-plots: http://informationandvisualization.de/blog/box-plot

Is there a way to get static SVG (i.e. no JavaScript) out so you can incorporate the chart into a document, edit in Inkscape, etc., or does SVG+JavaScript inherently mean that the result is stranded in the browser?

Checkout SVG Crowbar:

http://nytimes.github.io/svg-crowbar/

Thanks! It's unfortunate that it's Chrome-only. It worked well on their examples, but not on this (not a d3.js):

  http://www.cluster-text.com/tmp/news.svg

Still, it's an interesting start.

Correction: It somewhat works if you wrap the SVG in HTML:

  http://www.cluster-text.com/tmp/news.html

although, when I load it into Inkscape the positioning of some text labels is way off (some aren't too bad) and some hidden elements are displayed.

FWIW the horizontal & vertical charts are reversed in the preview images.

Thanks, fixed.

Any blog post detailing the reasons for choosing D3.js??