5 ms·
My problem with d3 is that it's a very leaky abstraction, and there's no clarification about what, when, and where things must happen, versus can happen, versus
by j2kun 8y ago
My problem with d3 is that it's a very leaky abstraction, and there's no clarification about what, when, and where things must happen, versus can happen, versus must not happen. A core example is data joining. If you don't include .merge in just the right place, everything breaks with no warning or errors. A better design would eschew the implicit "state" of a selection (entering, updating, or exiting) in favor of providing three distinct, named handlers for the three stages.
The result of things like this is that d3 encourages mindless copy/paste, and you either have no idea how it really works, or else you've scoured the d3 source to understand what's going on (which then requires expert level of javascript knowledge).
- BigJono 8y agoI mean, you're always going to run into this problem with this kind of library. Building a big, complex data visualisation pretty much requires expert knowledge in whatever language/environment you're doing it in. Law of Leaky Abstractions and all that. The purpose of something like d3 isn't to hide everything from a newbie, it's to make the code a bit cleaner and save the expert developer a bit of time. I think beginner programmers in general expect too much from libraries.
- j2kun 8y agoThere are obvious, concrete ways to fix the API that would reduce the problems, for beginners and experts alike.
- mr_toad 8y agoI blame a lot of the tutorials for the ‘mindless’ copy and paste. Short blog style articles are not the best way to learn D3. You really need to sit down for a few days and work hard to understand it.
- thebooglebooski 8y agoI'd note the official documentation isn't intuitive either. Which lends itself to all of the tutorials that seem to promote mindless copy paste, because authors would rather paste their code, than explain why parts of the API are strewn together in a particular way. I spent the last week trying to understand the brush and zoom APIs, and everyone from stack overflow to medium to bl.ocks just seems to push a style of learning that lends itself to "just look at this example, and figure it out from there." So while sort blog articles are not the best way to learn D3, I think a better job could be done in illustrating the mechanics, models and use cases through geometry, and explaining what subset of a particular API are absolutely required to achieve a goal.