I have a dataviz side project, and I'm curious to learn d3 to improve the web rendering. Right now I'm generating png images with matplotlib and showing those with <img>. It's very decent, but it would be much better with svg or html. The task looks daunting though because it sounds like what I actually need to learn is 3 separate languages: d3, SVG and javascript. Then redo all the fine tuning of styles and themes I did in plt again. A lot of work.
Those are based on writing a declarative description of the chart(s) you want in a domain specific languag. They will be less flexible than d3, but should make it simpler to get good results as long as you don't want anything too custom.
Disclaimer: I haven't used them myself, but they are from the same university research group that Mike Bostock (d3 author) used to be in, and I have seen him plugging them.
You will likely find any of these approaches quite different to matplotlib. Hopefully in a good way.
Despite having suggested these alternatives, I would actually strongly recommend learning d3. It's really good.
There is a lot of nuance to writing a full-fledged charting library, particularly when spanning across languages. Try not to reinvent the wheel, when there are already mature projects with the same goals:
Well you should learn all 3 to be confident and professional at it. For a side project, I'd start with d3 examples. Barchart, Line chart. Get a feel for how things flow in d3. Plus you have something working to make you smile. You'll pick up a bit of js on they way too.
Next you want to study, one chart in detail for how d3 works internally. Select-enter-append-exit cycle, how data rows show up magically as params, how scales work, domain-range mappings etc.
Now you can pick up some js idioms and syntax. Having seen some in your chart code, it should not be too daunting. And most js knowledge is just a google search away. Keep at it. Limit yourself to whats useful in charting. Try not to get sucked into becoming a master at js.
Now you should feel quite confident. Up next SVG. This takes a lot of effort, time and patience. I'm still learning SVG so cant comment on that.
But one important note is to keep working versions of your handmade charts in a git repo. Makes it easy to see your progress and something to keep you on track when you feel like its a lost cause.
>> Up next SVG. This takes a lot of effort, time and patience
Because SVG's not that different from HTML, I simply cheated when it came to learning the basics.
I would just create a base image (like a bar chart) in something like Inkscape and then open the file up in a browser.
I would then manually manipulate the SVG code in a text editor (or a browser's development tools) and refresh the browser to see changes. You get the feel for how an SVG image works pretty quickly by adding and removing elements and altering attribute values, etc.
On web projects where I'm using something like Haml, I sometimes create SVG templates in Haml (from a base Inkscape file) if the requirements for the image are simple and specific. I've used this method to create donut charts, and small microcharts like bar charts and win-loss charts. The amount of template code I used was minimal, and there was no large client side library required.
Disclaimer: I know this is not the best way to learn how to create SVGs, but it worked for me for certain use cases. YMMV.
Nice! Very timely for me too, I was just doing some D3 stuff this morning, and this very clearly explained what's going on under the hood.
I was definitely in the "copy/paste pieces of code from various snippets over at bl.ocks.org, cross my fingers and hope for the best." camp. It makes much more sense now.
