61–70 of 75 posts
D3 is painful, we don't have to appeal to authority to admit that. Mike Bostock is an interesting person, and a case study in why we don't design languages from a single person's genius.
Yes, we do. Do you want design by committee?! If you don't like it, don't use it. I don't!
Man, my first startup in 2010 used protovis, the charting library Mike Bostock built before deciding d3 was the better approach. It was rough to have an 8 month old startup with a core piece of tech that suddenly stopped improving. My main takeaway from so much of this is that "just a chart" is one of the biggest sources of hidden complexity in displaying useful information to people. It's right up there with "a simp…
All other libraries will just have a pile of abstractions that will leak everywhere as soon as you deviate from the happy path.
If you just want a bunch of auxillary charts and don't need a ton of control, just use something like ECharts. When you want real creative control over your visualisations, don't bother with anything high level.
Also, I've come to really dislike libraries that use this kind of `a.b().c()` chained form:
boxplotContainer
.append("line")
.attr("x1", xScale(gender) - boxplotWidth/2)
.attr("x2", xScale(gender) + boxplotWidth/2)
That, and I really never got comfortable with the `.enter()` and `.exit()` and `.join()` concepts. It's so abstract.
Note: the example is a misconception and not what's meant by "binding to data." In D3, binding to data refers to using the `.data()` method to supply an object (typically an array) which you can then use in a function callback in the accessors, so like `.attr('x1', d => /* access individual array item here */)`. This allows you to easily bind a dataset to a graphical representation and use its attributes to inform th…
That's like saying that your car is no slower than walking. You want your visualisation library to be a big improvement on not having one, not "no worse".
I tried D3 a few times, with some success, but eventually abandoned it. The mental model it requires is so different from other charting libraries it seems too difficult for my brain to grasp for any period of time. Also, I've come to really dislike libraries that use this kind of `a.b().c()` chained form: boxplotContainer .append("line") .attr("x1", xScale(gender) - boxplotWidth/2) .attr("x2", xScale(gender) + boxpl…
I don’t know D3, but usually in these chaining approaches it would be something like:
boxplotContainer
.append("line")
.debug(callable_thing)
.attr(…)
I could not get over the fact that 0,0 in d3 is the top left corner instead of the bottom left. Why?? Everything in real life uses bottom left for 0,0! Probably because the first EGA/VGA accelerators worked this way to save one instruction in the most common use case and things never change....
"Everything in real life" made me laugh out loud.
Man, my first startup in 2010 used protovis, the charting library Mike Bostock built before deciding d3 was the better approach. It was rough to have an 8 month old startup with a core piece of tech that suddenly stopped improving. My main takeaway from so much of this is that "just a chart" is one of the biggest sources of hidden complexity in displaying useful information to people. It's right up there with "a simp…
I've worked a lot with dataviz over the years, and after fighting so many libraries, I've finally stabilised at plain d3. Even in React projects, I'll just use the d3 primitives and build SVG from that (ignoring all the d3 DOM stuff) All other libraries will just have a pile of abstractions that will leak everywhere as soon as you deviate from the happy path. If you just want a bunch of auxillary charts and don't nee…
I tried for a few years to help Streamlit deployments in production. Never will go that direction again. Litestar + React with echarts or d3 is the way to go. Or use your favorite application backend, but REST is almost certainly the way your use case needs to go.
Earlier quoted context omitted.
I've worked a lot with dataviz over the years, and after fighting so many libraries, I've finally stabilised at plain d3. Even in React projects, I'll just use the d3 primitives and build SVG from that (ignoring all the d3 DOM stuff) All other libraries will just have a pile of abstractions that will leak everywhere as soon as you deviate from the happy path. If you just want a bunch of auxillary charts and don't nee…
I like d3 and echarts. Everything else feels a bit hacky. I tried for a few years to help Streamlit deployments in production. Never will go that direction again. Litestar + React with echarts or d3 is the way to go. Or use your favorite application backend, but REST is almost certainly the way your use case needs to go.
First of all, shocked people still use d3. Hasn't there been something better? It's pretty ancient by javascript standards. Do people still use jquery too? Haha... been about a decade since I touched this stuff! Second of all, isn't it ungodly slow? I get that it can draw a few boxes nicely, and maybe shuffle them around, but I had to write my own engine using html canvas because d3 couldn't get svg to flow properly…
Man, my first startup in 2010 used protovis, the charting library Mike Bostock built before deciding d3 was the better approach. It was rough to have an 8 month old startup with a core piece of tech that suddenly stopped improving. My main takeaway from so much of this is that "just a chart" is one of the biggest sources of hidden complexity in displaying useful information to people. It's right up there with "a simp…
I've worked a lot with dataviz over the years, and after fighting so many libraries, I've finally stabilised at plain d3. Even in React projects, I'll just use the d3 primitives and build SVG from that (ignoring all the d3 DOM stuff) All other libraries will just have a pile of abstractions that will leak everywhere as soon as you deviate from the happy path. If you just want a bunch of auxillary charts and don't nee…