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

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.

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

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.