Britecharts: D3.js based charting library of components
eventbrite.github.io
eventbrite.github.io
Side note: Anyone know why "calendars" don't qualify as part of these packages? I just have a series of data and want to render it on a calendar-graph instead of some typical data rendering... too abstract?
What this essentially means is that you are able to build your own visualisations. If you for instance check this sample[1], and in the JSON editor, inside the "encoding" section you swap x with y, and y with x, then click on the parse button, the chart will be redrawn with the x and y axis flipped.
[1] https://vega.github.io/new-editor/?mode=vega-lite&spec=bar_a...
There is some more sample code and charts in the introductory blog post at https://www.eventbrite.com/engineering/introducing-britechar...
My colleague posted a followup to a question on a blog post he wrote that goes into more detail about this topic if you're interested:
https://www.eventbrite.com/engineering/introducing-britechar...
UPDATE: Ah, it's (somewhat) in a third post: https://www.eventbrite.com/engineering/introducing-britechar...
d3 was too low-level for my tastes (There are two types of programmers - builders and disassemblers. I'm the latter in that I like to start with something working and figure out how to take it apart).
I toyed with Vega, nv3d, Bokeh and they all had great things going for them but nothing felt like it had nailed "making the easy things easy, and the hard things possible".
disclaimer: I'm the founder of plotdb.com
One other big difference is that Britecharts is compatible with the latest version of D3. D3 V4 underwent a major refactor to increase modularity. NVD3 is actively looking for volunteers to help them get there though - https://github.com/novus/nvd3#do-we-support-d3-v4x.
Disclaimer: I work with the folks who develop Britecharts.
Specifically, stacked against C3, Britecharts has a more 'D3-like' API, while C3 is a lot more declarative. This means that on C3, we will render charts by passing large configuration objects, while in Britecharts we strive to use a different API, chaining settings like we do on D3.
Also, C3 hasn't been updated to D3 v4, and we can say it is an inactive project.
We've had it in production for a couple of years now. The best thing about it was it got us off the ground quickly but at this point I think we've likely sunk more hours into debugging issues and hacking features than it would have cost us to have built it with d3.
Edit: actually every demo keeps restating itself when I scroll up and down on iPhone
Thanks for the bug report! I will create a ticket for it and check it out soon.
From what you said, it seems scrolling is triggering a viewport resize, so we will review our viewport resize listener on the demos (it's not really inside Britecharts).
Thanks again!
I'm an author of a JS charting library myself, so here is something I'm proud of - https://worldoscope.cxjs.io/8nhpbo6
http://162.243.163.202/profiles/76561198074712603
I'm using chart.js but since I only have two charts so far I'm free to change my charting library. Maybe even to OP's Britecharts or your library.
Here's the source btw: https://github.com/veggiedefender/steamlog
As a Steam player myself, how can I see my own stats? I tried searching by my username, but couldn't find it...
relevant logging code: https://github.com/veggiedefender/steamlog/blob/master/steam...
I decided I'd use Javascript for it because I thought it would be simple and have very few dependencies (ideally only a web browser required). Normally we'd use commercial packages. The vendors of our control system software supplied a Microsoft Sharepoint plugin that could do live trending straight out of control system. But required an adobe SVG viewer plugin to be installed on the computer. There were some issues with deploying (needed specific versions of browser etc would have been a nightmare to update absolutely everything. The plant IS people were extremely conservative insisted on LTS versions of everything did not like upgrading software, especially not in somewhere like a control room). So I thought I'd skirt around the issue by using Javascript.
My only other experience writing trending packages was using a very ancient library called "SL-GMS" we used this software to write in house operator guidance screens. It is C++ based but very powerful I didn't want to write a full c++ program just to trend something.
At the time I found the project utterly infuriating. Not so much the trending packages although I hit issues with a few a lot of them used sVG as well :(
The javascript language around the trending package was where I found most issues. Esecpially trying to interface with the data. It was a really really frustrating language to program in.
It was my first time trying to write javascript and I got bitten by absolutely every bug you could think of. So I was probably a bit naive thinking Javascript would be "simple".
For my day job I maintain a web analytics dashboard for car dealerships. We use c3js with React, and aren't crazy about it. Actively looking for a replacement.
Outside of work I use d3 for more interesting stuff: http://www.matthewparrilla.com/mansfield-stake/
[1] - http://c3js.org/ [2] - http://www.chartjs.org/
What would you use for a very custom chart (something like a Gantt, say) ? D3 or something like snapsvg.io ?
I used to like Raphael a few years ago..
Can you explain what you mean by D3 + canvas? A secondary view?
And don't even get me started on trying to make D3 charts responsive ;)
You have to work with the DOM + JS at fairly low abstraction level in order to get an output out of D3. It is be definition reusable.
It is extremely powerful though!
And, on most screens - even smartphones - they don't need to be responsive at ordinary dimensions.
Usually, the request seems to indicate a fundamental lack of understanding of how D3 is meant to be used, or design/page layout flaws that get dumped on the chart code.
> Is the most apparent benefit less lines of code?
Yes! With "reusable components" you don't need to write (or copypaste) a line chart over and over.
From their demos:
brushChart
.width(containerWidth)
.height(300)
.onBrush(function(brushExtent) {
// Do something with the brushExtent
});
brushContainer.datum(dataset).call(brushChart);While D3 is low level, it's in no way just a "wrapper around SVG with some sugar thrown in".
Besides the tons and tons of helpers for scales, mapping, projections, calculations and all that jazz (including the animation stuff with enter/exit etc which you did mention), it's also a whole functional concept on top of the drawing primitives.
One could theoretically even remove SVG and add another rendering backend with D3 with the same top level primitives.
Thanks, we are super excited about releasing this project as Open Source, it's been such a trip!
Totally, D3.js is a fantastic low-level library and is super reusable in all senses (examples, low-level plugins, different reusability patterns). However, one of D3.js usability problems comes from its main advantage, how powerful it is!
This means that D3 has a very low-level granularity and a huge API, making it hard for newcomers to create a simple chart for a dashboard or a one-off data viz.
That's one of the reasons why we created Britecharts, to democratize D3.js charts, and at the same time, serve as a stepping stone to those who want to learn more about D3.
In our mind, using Britecharts, a junior developer could render a chart quickly, just doing d3 selections. Then, she can start tinkering with one of the charts and even create a new one, learning d3.js in the process.
We are super interested to know what we can do better on our docs, any feedback would be great!
What do you find is missing on the examples? Would you like more info about when to use each chart? Or more examples of the different configuration options?
That's a great question! We at Eventbrite are looking into improving our accessibility, our designer Sun is pushing for it on this issue: https://github.com/eventbrite/britecharts/issues/168
In that link you can find some references about accessibility on other libraries and best practices.
And also we can extend it to support say drilldown charts?
Totally! You could fork the library and modify the charts if that's what you need. The source code is based on the reusable API (https://www.eventbrite.com/engineering/leveling-up-d3-the-re...), and it should be easy for D3 developers to understand the code and extend it. Our development environment also provides with the demo pages that can be used as a sandboxed context, and you can make use of our current tests to keep the code well tested!
Regarding the drill down charts, in theory, is possible!
I'd prefer to simply load d3.js, then britecharts.js on top of that, and be on my way. This is how metricsgraphics.js worked, and it was super simple to take into use.
I am sorry that you just find our current bug with the build! We have an issue about that, and we will be trying to fix it ASAP. I totally understand, having all the charts available in one file is an important use case.
In the meanwhile, you can use the individual chart bundles, like '/dist/umd/bar.min.js' and either load it with require/commonJS or load it with a script tag (it would be assigned to document.britecharts.bar).
It's a wrapper around both D3.js and crossfilter.js and makes building linked interactive charts / dashboards really easy.