4 ms·

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 ha

by Nemcue 11y ago

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.

couchand 11y ago
I disagree that there's any problem with the API. I do agree that it can be hard for a new developer trying to learn, but I believe that it's worth it. By analogy, learning to code is hard for someone who has not yet done it, but it's still worth the effort, and you would never expect designers of "real" programming languages to dumb things down to make it easy for you the first time. Should we design our tools so that you can pick them up immediately or should we design them so they give us as much power as possible? I, personally, would prefer Englebart's violin.
- Nemcue 11y ago
  "Should we design our tools so that you can pick them up immediately or should we design them so they give us as much power as possible?" A thoroughly false dichotomy. It's not either or, it's varying degrees of both.
mgold 11y ago
If someone thinks selectAll is inconsistent, they probably don't understand the central enter/update/exit pattern [1]. D3 is a powerful _drawing_ library and I've used it for totally custom visualizations where no canned tool would suffice. I think there's an un- or only partially-filled niche for more customizable _charting_ library that is more user-friendly. [1]: http://bl.ocks.org/mbostock/3808218 http://bl.ocks.org/mbostock/3808218
deleted 11y ago
[deleted]

by Nemcue 11y ago

couchand 11y ago

I disagree that there's any problem with the API. I do agree that it can be hard for a new developer trying to learn, but I believe that it's worth it. By analogy, learning to code is hard for someone who has not yet done it, but it's still worth the effort, and you would never expect designers of "real" programming languages to dumb things down to make it easy for you the first time. Should we design our tools so that you can pick them up immediately or should we design them so they give us as much power as possible? I, personally, would prefer Englebart's violin.

Nemcue 11y ago
"Should we design our tools so that you can pick them up immediately or should we design them so they give us as much power as possible?" A thoroughly false dichotomy. It's not either or, it's varying degrees of both.

mgold 11y ago

If someone thinks selectAll is inconsistent, they probably don't understand the central enter/update/exit pattern [1]. D3 is a powerful _drawing_ library and I've used it for totally custom visualizations where no canned tool would suffice. I think there's an un- or only partially-filled niche for more customizable _charting_ library that is more user-friendly. [1]: http://bl.ocks.org/mbostock/3808218 http://bl.ocks.org/mbostock/3808218

deleted 11y ago

[deleted]