Hacker News new | past | comments | ask | show | jobs | submit login
How to learn D3.js (wattenberger.com)
895 points by slowhand09 74 days ago | hide | past | web | favorite | 106 comments

D3.js is great, DC.js is amazing. https://github.com/dc-js/dc.js

DC combines D3 and crossfilter for multidimensional filtering so you easily do things like click an element to use it as a filter for your other elements.

I think crossfilter is a huge success and amazing project, in spite of its small size. Why? The code hasn't been updated in 4 years and it still works.

You don't have to be constantly tweaking and tweaking everything all the time. Crossfilter is like the I-Beam of construction.

I wish we could do this with more computer science parts. Building something amazing and leave it alone. Move forward. Stop spending all our time inventing and learning new libraries, frameworks, architectures all the time and get stuff done!

This is a great goal to strive for. But to play devil's advocate, not all ideas and scopes are clear until several iterations in. Furthermore, some software projects carry around specific dependencies necessarily. If these dependencies are prone to change then there goes your stability. Given enough dependency incongruity, all projects die after a long enough period of non-maintenance.

You are totally correct by the way. I do agree that most software creators hand wave away the potential for their dependencies change faster than they can maintain their own product.

My mind was just blown because of D3.js, and now you're hitting me with DC.js? Mercy!!! (joke)

D3 is stunning. I've been looking for a nice visualization framework for some internal reports, and this (D3 or I guess DC) looks like a great tool to add some spice to boring charts.

Javascript frameworks are almost overwhelming in the numbers and functionality now widely available. If only there were more hours in a day to spend learning them.

Yeah, DC.js is fantastic and I've used it extensively at work to build a really useful data exploration tool in Electron + React + dc.js . We even ended up making custom plot types like ROC curves, box plots, canvas scatter plots (for faster perf) and sortable tables. The latter 2 I've contributed back to the community and posted examples on my personal blog / github.

I do wish that there was a way to handle NaN in crossfilter. The highly functional style codebase for dc.js also makes it pretty hard to wrap your mind around the codebase and easily extend it. Still, it is a really amazing library and I'm always amazed at how useful the software we've build on top of dc.js is for data exploration.

Hey, could you link that scatter plot extension? I couldnt see anything in your bio.

I've just been adding DC line charts and about to add scatterplots but was considering plotly.js instead. I'll be dealing with probably a couple thousand data points so performance may be critical?

Sure thing. This is the github repo with the drop-in replacement [1] (I think this is also likely to make it into dc.js at some point in the future but the project is currently held up entirely by one courageous soul who is obviously limited in how much time he can dedicate to it)

My (mostly abandoned) blog has a bit more info on it, but isn't critical reading [2]

[1] - https://github.com/HamsterHuey/dcjs-canvas-scatterplot

[2] - https://www.intothevoid.io/data-visualization/dc-js-canvas-s...

Thanks for sharing this! Besides examples shown here [http://dc-js.github.io/dc.js/examples/], is there another resource for DC.js where someone who is new to both D3.js and DC.js can check out the demos and source code like Highcharts demo here [https://www.highcharts.com/demo]?

Shameful plug here - and yes dc.js is great! An alternative web-component based approach to dc.js is available here: https://github.com/PolymerEl/multi-verse. It is still based on Polymer 2.0, migration to lit-element in the way.

"in the way" (interfering or obstructing) -> "on the way" (forthcoming / can be expected)

i->o is a common typo; here it could be negating the intended meaning!

I recall seeing your project almost 2 years ago. A bit of unsolicited advice - It would really help if your Github and docs page linked to a few actual interactive examples showcasing the different chart types supported, and the general capabilities of your library. Screenshots really don't do justice to projects like dc.js and your lib that hinge on interactions between users and charts/data.

It also appears that your demo for multi-chart is:

1. Broken

2. Blocked by most browsers and requires manual override of security suggestions (probably related to https and some sort of cross-domain things going on).

I'd be curious to see any working examples like the one dc.js has on it's main doc page. Cheers

Thanks a lot for your advice! Live demo used to be working on webcomponents.org - one service powering them has stopped working...

I launched this approx 2 years ago - using it in prod, but not had proper time to devote on better doc/demo/presentation. Looking forward to it during current migration to lit-element.

Awesome. Sounds good. Best of luck! I know that it's hard to find time for any of this stuff when it's all a labor of love in your free time.

It just reminds me how far Kibana has.. moved since v3 :(

Wow, thanks for this!

As someone involved in computational geoscientific research, finding new ways to visualize and present data is a persistent challenge. We don't use Javascript much (read: ever) in day-to-day work, but I think there is enormous potential there for viz of post-processed data.

This article gives a great intro to D3.js, and I'll be looking into it more. A colleague also recently showed me Dash by Plotly [0] which may be of interest to folks in a similar situation.

[0]: https://dash-gallery.plotly.host/Portal/

My issue with D3 and other DOM-oriented systems is that it's rare I have a small enough amount data that it would work for them. There's a certain amount preparation and filtering that can be done, but particularly with time-series or geographic data, if you're in exploratory mode, you want to be able to slice and dice as part of the interactive browser presentation.

k is right that d3 has some helper functions for drawing on canvas, so most of the methods here will work:


Canvas is way more performant than SVG for a lot of shapes, since they don't have the overhead of a DOM node.

But in general, you want to work outside of the browser if you have that much data. What I'll usually do is either:

- write a python script to process my data and use d3 for the final visualization, or

- have an API that returns a sliced portion of the data and create an interface that will request different sliced datasets when interacting with filters, controls, etc.

This election dashboard is a good example:


it hits two endpoints, which return basically the maximum amount of data you can expect a browser to handle (the massive dataset is processed elsewhere). You could create an endpoint to return different views when you click on, eg, a different date, although then the user would have to wait for the data to load.

As far as I know, D3 can also render into a canvas, which should eliminate the DOM/SVG nodes overhead.

Yes, in my experience this can get to considerable scale (hundreds of thousands and beyond) but at a price. You need to do all your own management for things DOM/SVG were doing (e.g. hit detection, styling). You still need to send the data to the client and probably store it locally (customers will enjoy learning how to start Chrome from the command line with flags like --args --js-flags="--max_old_space_size=8192"). The client environment still doesn't have much support for data management or processing unless you bring in some other JS libraries. I'm a big fan of JS development but the criticism is on target.

True story.

There is no endless RAM, even for browsers :)

DOM-nodes are rather heavy compared to simple JS objects, so getting rid of them can bring some visualizations that are too heavy for the browser back into the realm of doable.

After that you have to optimize your other data-structures. If you have objects with many boolean fields or strings that are essentially used as enums, you can try to replace them with bit-fields, I read some library creators (BlueBird promise) got much performance gains with them.

This is where you want to make POST requests to an API you have / have built to get new data on the go! Of course, d3 is definitely still limited in scale, but just want to mention that technique bc it does allow you to slice & dice pretty huge datasets as part of the interactive browser presentation.

One of my colleagues, for his PhD research, wrote a jQuery-based tool to do something similar to that (still under development): https://pdfs.semanticscholar.org/a5b4/5bb7b0091963781390557e...

That's where DC and crossfilter might come in handy. One of their demos uses 250k rows of airline transit data and handles it well.

bokeh then

I wanted to ask the same question: how does it compare to Dash?

As a non-javascript user who does data visualization, I would love to have some advice about which technology(es) to invest time into

> We don't use Javascript much

Not even Leaflet? I've been using its R interface and I think it's fairly easy to pick up.

I'll take a look at it. For scripting, I'm mainly Python and Julia based, but R is definitely pretty common around here. Thanks for the info.

What does Julia have that Python or R lack ?


I like Julia as a language but the speed argument doesn't really apply vs Python. Yes, benchmarks against pure Python implementations look good but in reality no one uses naive pure-python implementations. Python (with all the bells and whistles that interop with C/C++ like numpy, pytorch, tensorflow, numba, cython...) is very performant.

Python (with all the bells and whistles that interop with C/C++ like numpy, pytorch, tensorflow, numba, cython...) is very performant

I know. I spend much of my days writing 'high performance' Python, and Python is still my go to tool for just about everything. Julia's big advantage is, kind of like Fortran vs C back in the day, that it's fast even if you're just writing things in the most obvious and natural way for your domain.

Just fyi

I used d3.js back in 2016 and it was already at that time very nice, but I always had problems to keep control of it (a lot of code and the end-results sometimes didn't work 100% as intended as my code did not cover all possible constellations of potential input data).

If I remember correctly after a while I then tried Cytoscape ( https://cytoscape.org ) and coding was a lot simpler and the results were more stable. I then dropped the project but I left with a positive impression of Cytoscape. There was maybe as well some other good candidate, but I just cannot remember anymore... (something that was doing at that time initial experiments with WebGL as optional/secondary output-engine - was it Cytoscape or something else?) .

Of course if you need max flexibility and very special results then D3 is #1.

For anyone confused by the link - Cytoscape confusingly exists as both a javascript library and a Java desktop application. Cytoscape the desktop application is a very biology-focused network visualization/analysis platform, whereas Cytoscape.js is a pretty general purpose network/graph library. You can find Cytoscape.js at [https://js.cytoscape.org/].

I used Cytoscape on a recent project[1] after trying d3 initially. It still works beautifully! Although its performance is not so great if you have more than a thousand nodes/few thousand edges or so.

1. https://github.com/mixer/webpack-bundle-compare

D3.js was surprisingly pleasant for me to work with. It made it pretty easy to implement x-splines.


Some day, I should try to work and get x-splines into more drawing programs; I really do find them a lot easier to work with than other kinds of splines.

this is really great, thanks for sharing! I like the linked Papers We Love slides - wish I could have seen the presentation!

Yeah, for better or for worse, talks are intentionally not recorded. The idea is that this way people will be less afraid of asking questions and it's more of a guided discussion than a one-way presentation.

that makes total sense, and I love the concept. (even though I also want the recording of the presentation!)

Great intro. I got the book and it was really good. I don't know or have any association with them, just a satisfied user.

Good to know. I got the free 1st Chapter and am considering the entire book. D3.js is awesome. You buy the std or the deluxe version?

I've gotten the React and RN books from FullStack. I reference them regularly because they're both great workbooks and reference books. I'm sure Wattenberger's D3.js book is similarly exceptional.

What kind of experience level would you recommend the React book too?

I've done small frontends in Angular 1, pure JS, jQuery, and fiddled around with newer Angular and Vue. While I found Vue pretty intuitive, I kind of got stuck jumping from the little tutorial components to a full page - how to organzie components, the code modules themselves, etc.

It seems React is eating the frontend world, so I've always kind of kept it on my to-to list.

it is! and thank you for submitting this to hn, I really appreciate it

To give you a bit of context, the _large_ majority of people buy the advanced package (which really surprised me). The advanced package really just tries to bring all of your new knowledge together, going over d3 + React and d3 + Angular. It also has detailed walkthroughs of 3 complex data vizes, which could be really helpful. But both versions give you a great foundation to build off of.

I've been a lurker on FlowingData for a while and envy the vis practicioners that produce so much of this stuff. And My fav has always been the d3 stuff. But alas, I left development behind years ago for database and architectural work. If I make time to buy a copy and work it perhaps I'll write a review from a newbie perspective. You have a twitter handle?

hey do you know if i need to learn jacascript first before diving into this book?

previous experience with javascript is helpful, but not at all required. I spent a lot of time working in resources for people new to web development so that everything would be accessible and to keep readers on track.

so great to hear it, thanks for the kind words!

Can someone familiar with d3 describe why you'd use it instead of the many libraries that use it under the hood? For example, I think either bokeh or plotly uses it, but you don't have to learn any of the d3 details, and also have more capabilities like webgl.

One of the frustrating things w this whole ecosystem is you basically have two choices:

* Use one of those higher-level libraries (bokeh, plotly) to create a chart that looks exactly like every other chart made by that library

* If you need to do anything custom, at all, you end up having to build from the ground up w d3.

In other words, those libraries are super cool and I use them on the reg, but they offer little to no customization, so people very often end up back at the bare-metal build-it-yourself-w-d3.

I can't speak for other libraries, but Plotly is extremely customizable: you can change pretty much color, font, dimension etc. There are thousands of attributes which can be tweaked, from the length of the tick markers to the exact positioning of the titles, the shapes of the markers, etc.

Here's the full Javascript reference for all of these attributes: https://plot.ly/javascript/reference/

it really depends on your use case! d3 is basically as close to the metal as you're going to get with visualizing data in a browser. It lets you build custom, interactive visualizations, and really is just a rocket booster. If you just want a simple chart and don't need much customization, there are tons of great higher level libraries that are easier to use.

OK so I have been dreading doing some graphing work for too long now and am curious if anyone can help point me in the right direction.

How would you go about creating a live stock chart graph with D3.js?

All of the tutorials I have read assumed that the graph data was set in stone. Take this data, produce this graph.

I have created a few mathematical indicators for equity price predictions based on live data feeds, and I want to visualize them in real time in a graph.

Do you just keep rebuilding the graph every time a new datapoint comes in?

Mike Bostock's got some examples of charts that update without redrawing the whole thing (for example [1]) - you update the bound data and the bars/points/whatever to be removed/added fall out "magically". The term you're looking for is the "data join" [2].

1: https://bost.ocks.org/mike/path/

2: https://www.tutorialspoint.com/d3js/d3js_data_join.htm

I recently had to make several charts (and types of charts). I found that to make a chart in d3 I essentially needed to know the nuances of how SVGs are created. I was also frustrated by the data format restrictions. Like my data was in X format but X format was unusable by d3; I needed to transform it into Y format. But now Y format was not usable for me in the rest of my app.

My conclusion was to just draw SVGs on my own and skip d3. Well I used it for some of the nicer function like determining nice axis label spacing and formatting strings. But, I basiclaly cut d3 out of the loop and things are better off.

If you know what you want your graphics to look like and they are relatively basic (maybe d3 is better a complicated charts, I didn't get that deep) then skip d3 and just create the SVGs themselves.

Most d3 examples will have a "draw" function that you call every time the data is updated. You basically bind your dataset to SVG elements, then D3.js will diff the new data with that bound data and decide what to update. A good intro to the concept:


I personally usually am working in a React app, so I would use that to render (and update) the chart.

However, that's a pretty complicated example to start with! You might be better off using one of the higher-level libraries, like this one:


There are a ton to choose from (just google `js candlestick chart`), and they can be pretty customizeable.

If you are comfortable learning from examples, http://bl.ocks.org is excellent. It includes a wide variety of charts, many created to demonstrate a particular concept in D3 or a specific technique. For example, this [1] might be helpful for you, since it explains the enter/append/exit workflow along with demonstrating how to update a visualization when the data changes.

1. http://bl.ocks.org/alansmithy/e984477a741bc56db5a5

Not to speak ill of d3 but it is worth checking out some of the other libraries that wrap around d3 if you just need a plain old line chart.

d3's power is that it is very customizable and it is surprisingly easy to just think of a chart format you need and implement it (and it is very easy to update as new data comes in, you can reload individual chart elements which is very cheap).

But...that comes at the cost of all the extra code needed to build the chart. If you are just building a plain-old chart, I would look elsewhere.

I have a data-heavy application. There is some stuff that is really domain knowledge and building those charts with d3 is worth it. But for the basic line charts or whatever, I just use plotly. Yes, that means a heavier page but it is worth it to move the complexity of multiple chart types out of my code.

Super detailed and interactive exploration of the whole D3.js API. Beautiful to click through, insightful to read!

Minor bug report in case the author's reading: in the "maps-and-globes" section it says "Change the projection in the dropdown below to see how they differ" but starts out with that dropdown populated with geoAzimuthalEqualArea while showing the projected map for geoMercator.

ah! thanks for flagging that, just fixed it.

Anyone know articles on how to integrate d3 with virtual-dom libraries like ReactJs ?

No article, but I've done it. You basically have to take on a lot of the creation of the SVG element tags yourself, since having both D3 and React manage the DOM is a bit awkward. However, a lot of D3 functions already give back most of the properties that you need to construct the DOM anyways. For example, the classic sunburst chart (example here: https://observablehq.com/@d3/zoomable-sunburst) can be constructed from the section of code that contructs and partitions the hierarchy:

    partition = data => {
      const root = d3.hierarchy(data)
         .sum(d => d.value)
          .sort((a, b) => b.value - a.value);
      return d3.partition()
          .size([2 * Math.PI, root.height + 1])
Some downsides to this:

* Zooming is non-trivial, you have to recreate it in React proper

* React has to re-render entire hierarchies or massive lists depending on the traversal method that you choose to use for hierarchical datasets (topological or depth first) and React chokes on these pretty easily since they tend to be wide and flat

* Quickly changing data sets can't really benefit from memoization or React.memo, since the layouts themselves will constantly change. It makes things a bit awkward when mixing with memoizable data.

However, once we got the groundwork down, we never really had to touch it again. It was much easier to maintain than the pure d3 implementation using useEffect or componentDidMount, since we didn't have to deal with any sort of DOM state ourselves any more.

It's covered in the author's book: https://www.newline.co/fullstack-d3#ch-react

I did it a few months ago without prior knowledge of d3, and little knowledge of React. I tried to keep it simple and have as much manual control as possible, such that I could apply the tips of d3 tutorials.

I essentially have a visualization class with an svg, and an update function for all the D3 stuff. The data is handed using props.

When the component mounts, or updates I call my own update function which sets the svg size, binds the data, and defines the enter/update/exit actions+transitions. Because I call update in the componentDidUpdate function, I had to catch 'fake' updates where the data hadn't changed, and abstain from state-updates such that I don't end up with infinite update loops.

  componentDidMount() {

  componentDidUpdate(prevProps, prevState) {

  render() {
    return (
      <div ref={this.gridRef} className={"VisContainer"}>
        <svg className={"VisSVG"} ref={this.svgRef} />
With this rather primitive structure, my biggest problem was with d3. While many tutorial cover the enter/update/exit model, they often don't go in-depth wth the key-function of the data binding. Probably because they often use date of form list<int> for their tutorial. In my case I had more complex data such that I needed to have efficient updates, using the filter function of d3.

status_quo69's answer is great, just here to add a few thoughts.

This is largely why I wanted to write a post like this - often "using d3.js" is what we think we need to do, but I wanted to show that most of the API is just utility functions. Here are the two modules devoted to manipulating the DOM:


I recommend (and follow) that you render elements like you normally would, and use things like d3 scales or d3.line() to convert your data into the physical aspects that are needed. I find it really hacky to do it any other way. I want to explore more, but I did a quick test to see which is more performant (letting React render a scatter plot, or letting d3 render a scatter plot), and pure React was 4x faster:


Of course, this was just one example, but it agrees with my hypothesis.

I do have a whole chapter devoted to d3 + React (and one on d3 + Angular) that might be worth checking out. I think it largely comes down to understanding your tools and being able to pick the parts of d3 that will be most useful to you.

I use them together and its awesome. D3 handles all the layout and scaling while react handles the dom. As a mostly native developer this combo has blown my mind. I can make awesome complex viz with like 1/5 the code I would need in say swift.

there's already react/D3 libraries. there's also ReCharts, and ChartJS which are wrappers on d3

I've been meaning to spend some time with D3.js for a side project. Bookmarking this, casually scanning this it looks like it's exactly what I needed. How's the book different from the web intro?

Good question! This is meant more as an overview, whereas the book dives right into practical examples, while gradually weaving the basic concepts in. The book is a lot more extensive and detailed, and gets into data visualization fundamentals and more advanced concepts.

If you're curious, the first chapter is free to download and gives a good sense of the flow:


I love using d3 to make visualizations, the only bad thing about it is that so many demos and tutorials seem to have been made on v3 which requires some minor adjustments to get the same code working on v4+.

The breaking changes from V3 to V4 was a real problem, imo. A lot of it was the same functionality just reorganized.

A better approach would have been to leave the old code running with stubs to the new method signatures. As it is, if you want to migrate code from V3 to V4, it takes a lot of mostly annoying and tedious work that could have been done once by a little bit of code that calls the new code from the old method signature. Have a d3V3toV4.js translator library in there if you want, but don't make people update years of code to get on the latest versions of the API.

It took me hours to realize that all those beginner tutorials are based on v3 while I included current v5 and nothing worked.

I was litteraly unable to use the current version and went to implement v3 code based on tutorial and demo availability.

To this day I'm still planning to port everything to the current d3 version some time in the future.

so true. I think this is one of the downsides of d3 being so prolific in the past.

all examples on Observable are up-to-date, so searching on here could be useful:


and if you find a bl.ock that you really want to port, this changelog could be helpful:


most of the changes are simple name changes that put the methods directly on `d3`: eg. from `d3.scale.linear()` to `d3.scaleLinear()`

This looks beautiful but it doesn't seem to directly attack the main conceptual barriers that I find people run into with D3. These are: how its API is driven in a declarative functional style rather than imperative, and properly understanding the mapping from data space into the domain/range of the plot. Without getting these concepts right up front it can be really confusing. I would introduce those ideas first right up front before talking about the other parts.

Yep. There is no point at all knowing anything that is presented here without understanding how the API actually works from a high level. For me it was an "aha" moment when suddenly everything made sense (and I realised how nice d3 actually is).

The other big problem with d3 is that you don't get much for free with it. Many people are surprised that you have to draw a bar chart using rectangles. But d3 doesn't "draw graphs", it just maps values from your data into attributes in the DOM. You have to know HTML, SVG, CSS, and, of course, Javascript very well already to have any success with d3.

Back in the day I learned d3 by reading a tutorial by Scott Murray [1]. It was perfect for me as it also covered the basics of javascript itself, which I hadn't used prior. It's written for v3 of d3.js, so a bit out of date now, I still wanted to give it a shout out - thanks Scott!

[1] https://alignedleft.com/tutorials/d3

Nicely paced intro to D3.js except for the part where it matters the most. The `d3-selection` section where this guide introduces "the pattern", things begin to go downhill as the author loses the audience they claim to be targeting.

`.enter()` and `.exit()` is not covered at all, simply outsourced to the guide/demo by Mike Bostock, which is actually a really nice demo however it also omits explaining the mechanism.

Thanks for the feedback! There were so many rabbit holes that I had to prevent myself going down - I scope creeped this article enough as it is!

I also specifically didn't want to go into the data join patterns for two main reasons:

1. there are lots of other articles that talk about it in depth, and 2. these days, I largely don't use it at all.

This is partially why I wanted to write this up, because the DOM manipulation parts can seem like an integral part of D3, but there are really only 2 modules devoted to it. I mostly use D3 for its utility methods, and a JS framework like React to handle all of the rendering, and I really want other people to be able to discover those functions without first "learning d3".

Your article is very impressive, really good work!

These days I also tend not to use d3 for DOM manipulation, but only for its powerful helper functions (d3-scale, d3-array, d3-shape, d3-geo etc.)

I even try not to import d3-selection except for very specific cases.

I’m using Vue for DOM manipulation, and computed properties play very well with d3 helper functions (i.e. a scale which auto-updates itself reactively). In a way it’s very similar to ObservableHQ’s reactivity. Most examples from Observable can be relatively easily converted to Vue with computed properties.

That's fair. In that case, that explains why you did such an excellent job with especially the sections regarding DOM manipulation. All the visualizations with the accompanying code and the transitions were fun to follow, clear and informative.

Awesome. Wattenberger's blog is also really good (from a cursory glance). Really impressive stuff, can't wait to read it all.

thanks! I'm always open to requests for new posts as well, if there's anything you want to read about.

It's nice to find a good D3 resource.

I've had a couple projects where I wanted to dive into D3.j but I found it to be a huge topic and most of the time I end up with a D3 related framework where I don't have to dive in to the depths of D3.... but still wishing I could learn D3.js directly.

If anyone is having issues loading this site like me -- it looks like DNSSEC for this site isn't validating properly.


What makes you think that? Like almost all sites on the Internet, I don't see DNSSEC set up for Netlify (or this content domain) at all.

You’re right, I must have totally misread that page I linked. My resolver was returning a bogus result, I toggled DNSSEC validation, and didn’t dig much further. Looks like it‘s an issue with my resolver on this domain. Odd, because I haven’t touched my configuration in ages and I haven’t seen this problem before.

oh interesting! I'm using a basic Netlify setup so I never looked into this. I'll check it out when I get a moment, thanks for flagging!

I'm running Netlify, and I also get errors on that tool on another site:

    No DS records found for [retracted].com in the com zone
    No DNSKEY records found
    [retracted].com A RR has value [retracted]
    No RRSIGs found
I wonder if all Netlify sites are "suffering". I don't really understand the problem or the % of users affected by this.

Isn't this just the DNS reporting to you that DNSSEC isn't configured for retracted.com and netlify.com at all? That's not a misconfiguration; it's the right configuration.

How is D3.js these days? I last tried to use it 4 years ago for a side project, and ended up using C3.js instead (its a D3 wrapper). Since then, I haven't followed either library's development.

I think I should have written more about this in the blog post. Creating data viz with d3.js is basically as low level as it's going to get for drawing charts in the browser. There are many higher level libs (most of which utilize d3.js functions) that make it easier, at the expense of customizability. For anyone who just wants a standard chart, there are tons of awesome libraries out there.

D3.js hasn't changed radically in the past ~8 years, mostly because it doesn't need to. The SVG API has been fairly stable (at least as far as what has been implemented across browsers), and the basics of visualizing data are static (eg. how to convert data values to physical values using scales.

We used c3. But switched to Vega-lite. It is another wrapper on D3 but it’s well thought out and the defaults are really good. It has university backing. We vega lite for our web based software (it reminds me of R’s ggplot2)


They have a python graphing lib too based on the same “grammar of graphics”


I think there are two things you need to know, the basic model of d3 (.enter() and all that) and to make use of the example code online you need to have a good intuition for how to translate from v3 to the current version.

Once you know those two things, I consider it unmatched for creating unique visualizations, particularly interactive ones.

Such a well paced tutorial, bookmarked!

As someone who wrote a lot of charts in d3.js I must say that just using React instead of d3.js is a lot less overhead. But that's my opinion.

I share your opinion! And that's actually partially why I wrote this post - it's really great to know the different utility methods of d3.js to help render a data viz (using React, etc).

Great site op ! Great intro for d3

Thanks. Looking forward to learning it myself.

Really nicely put together page.

This looks interesting, I am looking for a new way to plot my fitbit data exports (right now using Python with Pandas and Matplotlib), but I still need to find a good way to store all that data before plotting it!

You can easily automate [0] the collection of FitBit account data.

[0]: https://towardsdatascience.com/collect-your-own-fitbit-data-...

Do you know SQL? Storing it in a local PostgreSQL database and using PostgREST for D3 to access it would let you slice and dice in addition to graphing.

Yes thank you for the tip! PostgreSQL does sound like a great idea and it would be easy to add new data points since I can check against the timestamp before adding new data.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact