The thing I've wanted is a visualization library that also comes with the UI controls for configuring graphs: picking the graph type, picking the fields, picking the labels, picking the aggregation, axis settings, etc.
Almost no one is implementing libraries that do this. Everyone just keeps building "low-level" graph libraries that leave application developers to build up (in my case) crappy and inflexible configuration UIs.
my experience has been that non of these solutions provide enough control granularity, and i keep coming back to d3.js (or other libraries like deck.gl) and building my own UI.
In my case that is 100% true. What I actually want is R but for the web. All the JS libraries are either too simple and rigid or too low level like d3.
You can't have it both ways. You can't have a completely open data representation and an abstraction at a higher level than d3. What you are calling too low level is basically dealing with the fact the data can be anything.
What we really need is a javascript dataframe that everyone uses by default but that is not going to happen. Javascript culture is practically all about reinventing and trying to improve the wheel so we can optimally go in circles.
I think there is an emergent self interest at the group level to keep things complex and salaries growing on the front end too. The complexity and absurdity is hardly a bug at the individual level if getting paid.
The biggest difference IMO is that there is no default data representation that 99.99% of people use in javascript like pandas/dataframes/numpy/zoo in python/R.
I would even say javascript has better visualization libraries than GGplot but because there is no javascriptDataframe.plot('line') the visualization libraries end up down their own path because of different data representations.
My experience also is that every visualization library will lack something if you want to do anything beyond the most standard visualizations. Almost by definition it has to be that way.
Agreed, I think. Though, ggplot is very tough competition. And a lot of the niceties of small multiples and such are going to be a super power for folks using them.
I personally would avoid BI in the stricter definition (Superset, PowerBI, Metabase etc) unless you are building internal tools, as they have significant baggage catering for their designed use case.
Data viz used to be my playground, I feel like I can comment on this with some confidence. It feels like the selling point / value prop here is that it supports multiple FE frameworks, but that's where its strengths end for me. It almost looks like a coding exercise more than a library that people would use - seems a great amount of effort went into boilerplate, configs, packaging, documentation etc, but not as much into the features themselves.
The tell-tale brushes in some of the interactive graphs hint at d3 as the foundation layer, and poking through the configs confirms that. The real power of d3 lies in how it integrates data with the rendered elements - transitions, filters, being able to use one set of graphs to drive the parameters of another set, etc. With d3, you get interactivity for very very cheap, it's a missed opportunity here not to extend that (most graphs in the gallery seem static).
Overall there is nothing that makes this stand out over other offerings. Other commenters provided some good examples. I'd mention Altair/Vega as an example of powerful / configurable library that can be driven from either FE or BE. D3 as the gold standard of a low-level visualization primitives library with unsurpassed flexibility. If you're after something more out of the box with a DS angle, Dash does a decent job (and plotly.js for an overwhelming viz feature set). For commercial solutions, HighCharts, as much of a drag as it can be, is still the reliable beige khaki offering. CanvasJS would be another one in that space. If you want to dabble in 3D visualization, three.js is by far both the best starting place and the most robust library you can ask for. Honorable mention for dc.js, as they make good use of the crossfilter approach (driving context/selection across multiple graphs)
The js data viz space is quite full, with some heavy-duty, established players. To be a new entrant on this playing field, you'd have to bring something breakthrough to the table. Sorry.
You've cited D3 but I notice that you haven't mentioned Observable's Plot[0], a Javascript GoG that wraps D3. They're both Mike Bostock libraries, so Plot is the pseudo-"blessed" D3 high-level abstraction layer.
I'm not up to speed on the latest -- thanks for linking this, it looks great!
I've shied away from Observable, I didn't quite like the lock-in to their notepad-like env, and all the examples following what to me felt like a backward style. It's great to see they've produced a higher-level complement to d3.
I've come to appreciate the non-standard extensions they've made to JS too - the reactive cell model has greatly reduced the amount of code I've needed to write compared to a hypothetical React equivalent. It's my #1 platform for my small side projects these days.
I'll quickly note for anyone uncertain - Plot is pure JS so it doesn't have to be used in an Observable notebook. Will run anywhere D3 does.
Thanks for the great summary. It's been years since I was in this field so very helpful to hear what's now available.
What would you use to plot (or downsample and plot) data that updates every second or more frequently? E.g. IoT data streaming in?
I used dygraphs (I think) a decade ago and recently found Lightning JS and this comparison [1] to other libraries, but the LightningJS license costs are prohibitive outside of well-to-do project domains. And I don't have data that updates that fast - just don't want it badly sampled or drawn.
We really just need generative prompts and AI to decimate the field of dataviz.
99.999% of anything ever done in D3 is 100% useless visualization. The whole field of dataviz is largely much ado about nothing.
I just can't imagine in the next 10 years we don't see a generative prompt that spits out something with D3 and we can move on to something more useful. The end goal is easily described in natural language. We shouldn't need Oppenheimer as the project manager to make some SVG boxes and lines.
At least you can just encapsulate it in a custom element. Vue has good support there and allows you to "componetize" it with little overhead or development time.
Until a better library comes out, I'd highly recommend using Layercake with Sveltekit. It's a wrapper around D3 which allows you to build reusable components that are responsive and can load server side without JS on the client. It's not as plug and play as some libraries, but it's not too bad, and gives you a lot more customization options:
I’ve heard Vega/Vega-lite is years ahead of other options, mostly because its expression power which is deeply rooted from years of research and success in industry (Trifacta/UW). Curious if anyone can share a more through analysis or opinions
I would argue the reason it's powerful is that Vega embraces the Grammar of Graphics as first principles (think ggplot2). It's imo the way to think about graphics, but I may be biased.
Looks interesting! I’ve been looking for a simple bar/line chart component that doesn’t add megatons of size to my build. How much would this add – ballpark estimate?
It's using Dagre for its layered algorithm, which has been defunct for a while hasn't it? I think elkjs is usually the preferred alternative these days.
Not in an "I don't believe you" way, but in a "I would love to know what would improve it." Starting to push to clean up some web pages I've been close to at work, finally.
* The use of `useCallback` is confusing in the demo code and is entirely unnecessary.
* Inconsistent use of single/double quotes and {}'s for literal values.
* Non-idiomatic combination of JSX elements + raw HTML in strings [1]
All valid, but the thing that stood out to me most besides useCallback being weirdly inlined—and this is more important IMO—is how awkward everything around labels is. Surely there could be a base labels component that just takes `data`, or at least doesn’t require so much ceremony around the vanilla interface.
The Svelte and vanilla examples are almost identical, but the Angular example looks much more like I’d expect, which strongly suggests (to me) that this is an Angular library with support for other uses bolted on as an afterthought.
That’s all fine, but it probably won’t get much non-Angular adoption if there’s no further effort to make it feel somewhat more idiomatic in other environments. Even if it looks quite nice otherwise (which at a glance it does!).
I assumed the was just directionally wise? That is, it is clearly useless here, as there are no "dependencies" passed; but in a real app you almost certainly have something there.
Still digesting the rest. I'm curious why the mix of raw HTML. (Not in why it is a bad idea, but why it was felt necessary.)
In this specific case, having useCallback makes the demo code more complex and is unrelated to the actual concept being demo'ed to the reader. It's unwise to add unnecessary complexity if it doesn't add clarity.
More generally, adding useCallback is even directionally wrong unless you know _exactly_ why you need it ("for identity" is OK, "for performance" is almost always misguided because the cost of creating a closure is negligible).
I immediately like this project for being “framework independent” rather than agnostic. It’s odd how computing has fashioned a completely different sense for “agnostic” despite perfectly adequate and well understood words already existing.
Is your objection to “agnostic” its religious implications in other contexts? It’s a perfectly cromulent synonym for independent in this context otherwise.
Almost no one is implementing libraries that do this. Everyone just keeps building "low-level" graph libraries that leave application developers to build up (in my case) crappy and inflexible configuration UIs.