top | item 9549651

Replacing jQuery with D3

195 points| chrtze | 11 years ago |blog.webkid.io | reply

61 comments

order
[+] athenot|11 years ago|reply
We've been running with d3 instead of jQuery for almost 2 years. Some notes so far:

- d3.selectAll is more verbose than $() but in my opinion, that's not a bad thing as I try to minimize DOM selections anyways;

- transitions are another area where D3 really shines, for cases where you don't/can't use CSS transitions, like displaying a discreet popup status message.

- d3 data binding is oh so convenient, and that's where the real magic happens. Combined with a queueing system like postal.js, we pretty much have the same thinking model as React. The DOM is now an expression of the data, and D3's joins figure out what DOM elements need to be updated. It's slightly lower level than React, in that you specify what happens on enter/update/exit, but in terms of efficiency, it seems great (disclaimer: we haven't run benchmarks);

- if you happen to like CoffeeScript, D3 turns into a very elegant DSL that is consistent for DOM editing, styling and event handling. Here's a simple lightbox modal dialog:

    lightbox.shell = d3.select "body"
      .div "#shadebox"
      .style "opacity", 0
      .on "click", ->
        lightbox.removeLightbox()
        d3.event.stopPropagation()

    lightbox.body = lightbox.shell.append "div"
      .attr "id", "lightbox"
      .on "click", -> d3.event.stopPropagation()

    lightbox.showLightbox()
    return lightbox.body
- we've added a `.div` function that's shorthand for d3.append and automatically adds an id and/or class, to feel a bit more like Jade;

- one downside we found with D3 is that we can't just grab any jquery plugin and throw it in our app.

[+] the8472|11 years ago|reply
> - d3 data binding is oh so convenient, and that's where the real magic happens

It's great, but it has limitations. It only ever binds to a single `__data__` property on the DOM nodes (making it very very difficult to associate multiple sets of data through a single DOM tree) and which needs to be carefully re-bound to each sub-node if you wish to substitute the objects with new ones. And acting on the data (basically two-way binding) and then updating the d3 selection has to be done very carefully too.

I've run into many subtle errors that stem from this fairly primitive method of binding.

It probably could use some additional abstractions to make replaying updates on object replacement/modification easier.

[+] couchand|11 years ago|reply
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

    d3.selectAll('.foo').selectAll('.bar');
The D3 API consistency is so juicy and delicious.
[+] aleem|11 years ago|reply
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.
[+] chrtze|11 years ago|reply
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!

[+] talmand|11 years ago|reply
For consistency like that you could always go with:

    $('.foo .bar');
But I would assume you could do the same in D3?
[+] emehrkay|11 years ago|reply
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.
[+] ww520|11 years ago|reply
D3 is an amazing library. At first glance thought it's a charting library. Upon further usage realized it's more of a DOM manipulation library just like JQuery, with the additional support on SVG, which happens to do chart.
[+] Tloewald|11 years ago|reply
Jquery works quite well on SVG too. It's all Dom nodes.
[+] gnud|11 years ago|reply
The Ajax section is just not good enough.

The main reason I still use jQuery is that they unify their promise type with their ajax. It's easy to create code that works with any promise, ajax or otherwise.

[+] couchand|11 years ago|reply
It would be trivial to convert the callback-based method to a promises one in whichever library you're using. For instance, with bluebird[0]:

    d3.json = require('bluebird').promisify(d3.json);
[0]: https://github.com/petkaantonov/bluebird
[+] candu|11 years ago|reply
It's easy enough (as others have mentioned) to wrap d3.xhr() in a promise. I actually like that d3 uses callbacks here, leaving async control flow concerns to other libraries.

No, my main quibble here is that d3.xhr() is still short on convenience and flexibility as compared to $.ajax(). (For instance: you have to build GET URLs manually? No .contentType() as a shorthand for the header? No automatic JSON.stringify() when POSTing application/json data? No HTTP basic auth support? etc.)

[+] acconrad|11 years ago|reply
You should try reqwest if all you need jQuery for is AJAX
[+] frik|11 years ago|reply
Instead of JQuery and D3. You can also use vanilla JS5 nowadays.

http://vanilla-js.com/

[SPOILER: it's not a framework, it's simply native JS5]

[+] aikah|11 years ago|reply
both jQuery and D3 are "vanilla js". Just that the person that owns that page doesn't understand the difference between the DOM and Javascript.
[+] me_myself_and_I|11 years ago|reply
I've come to dislike all-in-one solutions. If D3 focused only in rendering there would be a few advantages like a smaller api and smaller file size.

It bothers me that I'm already using superagent for ajax stuff in a React project, and if I want to use D3 I will need to live with that extra bloat.

D3 is really amazing, and I'll be integrating it anyway.

[+] xiphias|11 years ago|reply
It seems d3 would be easier to use if d3(...) would be an alias to d3.selectAll(...)
[+] Nemcue|11 years ago|reply
Ease of use in the sense that you type less.

I think it would be harder to use from the perspective of a new developer trying to learn D3. selectAll already has way too many responsibilities in my opinion, making it totally opaque what d3(...) really does. OTOH I guess it's kind of the same with jQuery(..), since it can do both selectors as well as create new Elements.

D3 is one of those libraries that I really admire from a conceptual point of view, but boy do I wish the API was more newbie-friendly.

It's rather indicative of an API that has room for improvement when you start noticing just how many tutorials, videos and books that have to explain D3.selectAll. "Well, you see — sometimes it doesn't really select anything, instead it does this other thing"

Not to mention the source code. Very sparsely commented.

[+] dheera|11 years ago|reply
$ = function(foo) { return d3.selectAll(foo); }
[+] candu|11 years ago|reply
...in which case you'd have the same issue mentioned above with jQuery, in that

    d3.selectAll('.foo').selectAll('.bar');
    $.find('.foo').find('.bar');
are consistent, whereas

    d3('.foo').selectAll('.bar')
    $('.foo').find('.bar')
are not. IMHO, d3's API is cleaner.
[+] rip747|11 years ago|reply
Honest question. if there so many similarities between the two, then why not build the library as an jQuery plugin from the beginning?
[+] chrtze|11 years ago|reply
D3 implements many other features like scales and stuff. The two just have some parts in common when it comes to DOM-manipulations and selections.
[+] lightblade|11 years ago|reply
Just one feature missing: event delegation.

Event listeners in d3 are not delegated listeners. Implementing this feature actually is not an easy matter as you need to preserve the d3 data binding context and also attach to the nearest svg element because svg events don't bubble through it.

[+] _7fvc|11 years ago|reply
I use d3.select for data binding with DOM elements. For DOM manipulation, I prefer jQuery. That's the distinction. I don't see advantage of d3.select over jQuery DOM manipulation.
[+] Pinatubo|11 years ago|reply
What's the preferred nomenclature: d3 or D3? Even this article uses both.