Hacker News Reader

Comment by couchand | Hacker News Reader

A great reference for someone starting out with D3 looking to replace some basic jQuery incantations with D3 ones. I think this code sample is particularly telling:

jQuery

    $('.foo').find('.bar');

    d3.selectAll('.foo').selectAll('.bar');

The D3 API consistency is so juicy and delicious.

View on HN

Consistency has nothing to do with it. In jQuery you could just as well do:

    $.find('.foo').find('.bar')

It's just a different way of invoking it. The short-hand is more convenient since it accepts a selector as well as a plain DOM node and converts that to a jQuery elements. This makes things very easy and idiomatic.

Yeah but jQuery's find (and a ton of its other APIs) are so drastically different than any other programming language/library. `find` in just about any other language returns the first encounter of an item in a set, as opposed to jQuery's `find` which returns all matches in a set.

And don't even get me started on how jQuery hijacks `this` in callbacks...

jQuery's find is almost certainly more useful that way though, if not optimally named.

I can't understand though why you would claim to dislike jQuery providing you a useful 'this'. You prefer to receive the window object?

> jQuery's find is almost certainly more useful that way though, if not optimally named.

Useful but poorly named isn't useful.

> I can't understand though why you would claim to dislike jQuery providing you a useful 'this'.

I prefer programming language libraries to work according to the semantics of the underlying programming language. Is that so wrong?

Come off it. JavaScript's 'this' is meant to be usable in such a manner. http://es5.github.io/#x15.3.4.3

Using bind like that is perfectly fine in application code but I consider that a big violation of Principle of Least Surprise in library code.

Nearly every programming language in existence has some feature(s) that you can shoot yourself in the foot with. Does that mean you should do it?

It's pretty standard practice for JavaScript libs. How much do you actually use JavaScript?

That's true. I am still often missing the shorthand versions if jQuery when working with d3. For example doing something like this:

$('.foo').append('<div class="bar" data-selected="true"/>');

in d3 I have to go the long way:

d3.select('.foo') .append('div') .classed('bar', true) .attr('data-selected', true);

I have recently worked a lot with this plugin https://github.com/gka/d3-jetpack which includes some very nice helper functions!

d3.select('.foo').html('<div class="bar" data-selected="true"/>';

okay, didnt think of that solution! thx!

Wouldn't that replace instead of appending?

Yea, that's something d3 can't do: convert raw HTML to DOM nodes the way that $.parseHTML do.

But if you can do that...

d3.select('.foo').append(d3.functor(node));

For consistency like that you could always go with:

    $('.foo .bar');

But I would assume you could do the same in D3?

Yes, d3 uses CSS3 selections

https://github.com/mbostock/d3/wiki/Selections

Yes you can. Both libraries are based on document.querySelectorAll which has the same selectors as you know them from CSS.

jQuery's bad api naming shouldn't come as a surprise to anyone who followed JavaScript in the past 10 years. They used bind for event handling, proxy for binding, grep as some kind of filtering, keys and indexes are flipped in the looping construct, etc. etc. It really mirrors PHP's interfaces in a lot of ways.

JavaScript is a bad language from the start, not really deserving to be called a language. jQuery makes JavaScript usable.

Javascript is perfectly fine. I think you mean the DOM is historically an unusable mess, but even that is getting better these days.

I was definitely talking API design choices. A lot of libraries achieve the same tasks, sometimes more, than jQuery with more thought-out APIs.

Reply on news.ycombinator.com