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.
What OP posted isn't "low level", I'd describe it as low-feature, intermediate-level visualization library.
Dashboard - https://highcharts-demo.cube.dev/#/
Pivot - https://react-pivot-table-demo.cube.dev/#/
Query builder - https://react-dashboard-demo.cube.dev/#/explore
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.
Originally from Airbnb. Very powerful and flexible OS frontend BI tool
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.
https://unovis.dev/gallery works, while
https://unovis.dev/gallery/ does not
you need to navigate to https://unovis.dev/ and then click "Gallery" for it to segue you to the former
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]
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.
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.
1. https://github.com/Arction/javascript-charts-performance-com...
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.
b) Sadly, Apache Superset is the only "BI tool" that is both free and open source, so you don't have any choice in the matter anyways.
But the lock-in is less severe these days. The parser, runtime and standard lib are all open-source, so you can run a full notebook in VSCode https://marketplace.visualstudio.com/items?itemName=GordonSm...
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.
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!).
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.)
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).
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.
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.