Hacker News Reader

Comment by woah | Hacker News Reader

I suppose that everything is a matter of opinion, but d3's syntax is the worst combination of obtuse (".enter"???), cute (the incredibly obnoxious chained api), and cumbersome (all the mutation, and the fact that d3 code always ends up being a long string of procedural spaghetti).

Of course, it does have a lot of useful code around math, projections, etc.

This project looks like a very welcome step in the right direction, showing that d3's great math can be used with obvious, declarative syntax.

View on HN

Can you explain why do you feel 'enter' is obtuse? I found enter/update/exit pretty logical. I do agree that long-term value of Bostock's work is in other parts than data-binding, but I didn't find enter/update/exit particularly hard

I agree with you as well. The enter/update/exit cycle is actually very intuitive although the documentation could do a better job of explaining what the functions are doing to the DOM.

In this case, I think a little more verbosity in the names of these methods would assist in understanding significantly. For example, enterAnimation/enterTransition would increase the clarity for someone new to d3, or who has been away from it for a while.

enter is used to insert elements into the DOM; if there is data in the data-set which isn't represented in the DOM, then new elements will be inserted which have that data. It doesn't have to do with animations really, though you can animate those newly inserted elements if you wish.

I understand how enter works, but my point is that the naming is pretty poor. If I haven't been around d3 for a while, it becomes very easy to forget how it works because of exactly this. Its api isn't intuitive, which often indicates either bad naming or design - in this case, I would pin it largely on the naming, and the api design not facilitating understanding as easily.

are you objecting D3's API lexicon, or the entire notion of how it abstracts data, and binding?

".enter" actually makes sense in terms of describing how data flows through the D3 processing pipeline.

For me, the biggest problem is that d3 is a declarative library which you write code procedurally for. If you look at d3 code, it has lots of imperative-style verbs (enter) which are not readily clear.

Quite simply, there's an impedance mismatch.

Sounds like an opportunity for applying Ohm/OMeta?

+1 I couldn't express it better.

Reply on news.ycombinator.com