Hacker News Reader

Comment by jonahx | Hacker News Reader

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....

View on HN

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.

Reply on news.ycombinator.com