Hacker News Reader

Comment by weego | Hacker News Reader

Sorry, I don't get it. The code in any of the given example comparisons has no less obvious complexity and just removes the abstraction that writes the SVG nodes for you with having to explicitly write them in your JS which I similarly have never understood why we're intent on going back to.

Different for the sake of different is fine, but "preferable" is a bold statement that appears to have no evidence.

View on HN

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.

+1 I couldn't express it better.

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.

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.

Sounds like an opportunity for applying Ohm/OMeta?

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.

I agree with you that is his personal opinion about "preferable" way to use D3.

> "Unfortunately, I always find D3 code surprisingly difficult to understand and extend"

I would say something different - it is very easy to extend and create various visualization. It is easy to scaffold new chart (line, pie, box-plot, heatmap etc.) and customize it to specified needs. I'd rather say that it is difficult to create a brand new type of visualization which wasn't been already developed [1] and it is easy to understand by random folk.

[1] https://github.com/d3/d3/wiki/Gallery

Yeah. I think the premise is reasonable - d3 can be a bit of a pain, but I'm not convinced this is the answer.

It just makes it more declarative. That's all. One can continue with their preference.

Are you saying the react way is more declarative?

Of course it is! to start with, it looks like SVG, but also you only have to provide the state that you want and React adds and removes what is necessary, while in D3 you need to use `enter` and `exit` imperatively.

I'm just concerned about speed. Diffing works ok for forms but charts with 1000s of elements... let's see.

As someone who has worked with D3 and React a lot, D4 makes a lot of sense.

And the name is great!

enter() and exit() are declarative. You're not causing anything at all to happen, but rather declaring what should happen, in the form of a function, when new data is found or data becomes stale.

Declaring 'what' structure should exist

- vs -

Declaring 'how' this structure is created

It sounds like the difference is just syntactical. Is this true? I have no experience with react, so I wouldn't know.

D3 is more declarative than jQuery, but not so much as React.

selection.enter().append("div").attr("class", "bar") .style("height", function(d){ return d + "px"; }) .style(“margin-top”, function(d){ return (100 — d) + "px"; });

enter is not imperative, but what you write just afterwards is.

The problem is that calling a function called "enter" does not feel like writing declarative code.

It's an active verb and seems to imply an imperative style. Except it's actually declarative. The problem with d3 is that it takes a declarative system and gives it an imperative-looking API.

I think you're reading it wrong. `enter` isn't imperative. You're asking for the `enter` selection, which is the list of entering nodes. Same thing with `exit`. Calling either of those methods doesn't actually alter any data

I know enter isn't actually imperative. That's the problem: it looks like it should be.

If I write "node.enter()" it definitely looks like I'm making the node is being made to enter if you aren't well-versed in d3.

And SQL `SELECT` statements looks like I'm actively selecting something, when in reality I'm declaring what bits of the table I want returned... All syntax looks opaque until you understand the underlying concepts.

Uh, a SQL SELECT statement is actively selecting something. You're selecting what you want to return. Terrible example.

The problem with "enter" is that nothing will happen if you simply use enter by itself. Yet it's an active verb which seems to imply that something will be made to enter.

SQL SELECT declares what will be selected when the query is run. The query engine does the selecting, including figuring out how best to do it.

Yes, SQL is declarative.

But you still "SELECT" something to look at. A SELECT statement is, by itself, sufficient to get something to happen (for results to be fetched).

On the other hand, a D3 enter() does absolutely nothing by itself. You must do further calls for it to have any impact.

This is very off topic and ridiculous.

OK, if a SELECT statement is sufficient by itself, surely you can tell me the results of this:

    SELECT * FROM stuff WHERE thing=2

Of course you can't. Because every declarative process has two main steps: declare and execute. SELECT and enter() both only declare; they must then be executed against data in an engine to produce a result.

What we mean when we say "SQL is declarative" is that it doesn't provide instructions on how to carry out a task, and instead only provides a description of the outcome of the task, once it's been carried out. SELECT is declarative because it doesn't tell the computer how to do a query. SELECT tells the interpreter what you want not how to get it.

It might be proven to be more performant, as it's relying on React's virtual DOM rather than d3's presumably made-from-scratch data binding. Would love to see some benchmarks though.

Reply on news.ycombinator.com