I 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.
There are obvious, concrete ways to fix the API that would reduce the problems, for beginners and experts alike.
I 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.
Re:The Trouble with D3
by thebooglebooski on Wednesday June 13, 2018 @06:04PM
(#17307387)
I'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.
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).