[milroc]

Alexandros,

I think you're missing a lot of the core concepts around visualisation. d3 aside (for now) you need to consider what visualisation is. Your focus is on charts alone will prevent this from getting any traction. d3 is a framework but it is also in a way, a visualisation kernel. This means that it gives the individual flexibility to create and design interactive information visualisations without being hindered by whatever is enforced by some charting library (only limited by the DOM or whatever scene graph it is working with).

d3 can also be viewed as an extension of the concept of 'grammar of graphics' (for a reference implementation of the grammar of graphics see vega (http://trifacta.github.io/vega) or ggplot2).

If you're plan around this is to build a system in which angular handles a lot of the data binding work, I would recommend re-implementing something like vega in angular. Because this would be more compelling than creating yet another charting library that is just built using some combination of d3's data manipulation and angular DOM style. nvd3.js, chart.js, yui-chart, etc. all run into this point where the libraries are simple tools for developers to use but do not have the extensibility of a framework like d3 that allows more freedom in the design.

Now lets say you create a competitor to vega, the key differentiator would be animation, assuming transitions are trivial as you've explained in this post, I have very minimal experience aside slides and videos in angular to comment. While vega will have: canvas scene graph support, potential to build on top of systems like WebGL, native iOS, or native Android. You will then be tasked to figure out the 'grammar of interactions' (https://github.com/trifacta/vega/issues/28) in order to allow attributes to differentiate yourself from vega which is going to be a very hard (but fun!) task.

Aside: d3's line function isn't refreshed as new data is inputed (meaning that you would either have to do this inside of some custom directive (towards the vega style implementation) or do some hack-ish 'tick' style system (the reason force directed is being updated is due to the fact that it has it's own very small physics model which you are leveraging on tick, (also 'ticks' do not harness angular's or d3's data binding concept well))).

I do think there is space for a true competitor to d3.js that takes a more OOP and stateful approach (what the root of your annoyance with d3 seems to be). While there may be room for this, I also feel (note emotion not backed with fact) like these concepts are also what will build too many limitations that will hinder the project itself. This competitor will likely live within the web components community once it's no longer dependent on angular.js, but will likely hit walls (just different walls than the ones you're currently frustrated with d3.js) that are going to be hard to get through.

I have thought about this stuff in the past (http://bl.ocks.org/milroc/5519819 http://youtu.be/Hd2rye9a9kk) and recommended a wrapped directive approach for angular.js (and other MV*) but as I said above the next steps are going to be MUCH more difficult than we expect.

Cheers,

Miles

@milr0c

[jarpineh]

I have been reading Grammar of Graphics, but it’s a slow going. I don’t yet see where the connection is with D3 and the Grammar, though (probably since I lack knowledge of the Grammar and don’t yet grasp the whole of D3). D3 works best with SVG constructs, where elements and attributes are manipulated based on what functions return. These functions then react to data, but D3 doesn’t really know what is in the data. It merely binds it to element’s __data__ attribute implicitly so it can know what to change when node gets selected. It’s the developer’s job to choose the right elements and attributes where results should be placed. Resulting graphic is an SVG document, which can look as a cohesive graph if developer gets the parameters right. This structure is often hard coded into script and not done with specific grammar that could calculate the graphic parameters consistently and reliably. This might be since D3 is intentionally low-level, but then there are parts that try to do more abstract things (like axes, that generate SVG directly). I feel this contributes to the lack of reusability.

Popularity of frameworks like Angular and the recent appearance of Ractive and React, as well as Fastdom (not to mention ClojureScript) suggests to me, that easy, efficient and reusable DOM manipulation is a hard problem and there can be many solutions. Its because of this I’d like to keep using D3’s great functionality (for me the scales and geo module) without its use of selections and W3C DOM API. There are other ways to declare a graphic and bind it to data, but calculating points for lines should not be coupled to a particular style of DOM manipulation. I like D3 a lot for discrete visualizations, but creating many interdependent graphics (like map and bar chart from the same data with interactivity between them) is not as easy as with, say, Ractive.

What I understand of Vega is that it works as a kind of grammar for graphics, but one that completely encapsulates the DOM manipulation. This allows it to support other render target, like canvas. I feel that this is opposite of what Alexandros is suggesting, that is to use D3 where it is good, but not parts which clash with Angular’s view of the DOM. If Vega makes it easier to use its functionality without the renderer, that would be great, but I don’t know how well it supports D3’s great functionality. This is on my study list, though.