I'm finishing up migrating a large-ish web app from react-vis to echarts and am very happy with the results. There are a couple things to note:
- It's not very react friendly out of the box. There are some good wrappers that mostly fix this, and overall I view this as a strength as someday maybe the product I work on will migrate away from react. Our graph configuration may survive that migration assuming our next ui lib supports echarts in some fashion.
- it's not d3 based. This part is kind of a big deal. For those not familiar with the internals of js graphing, d3 has been a foundational lib for generalized graphing libs for a very long time ("generalized" here is meant to differentiate between something that can render 8 graph types versus a jquery plugin that can render only a bar chart). I'm curious if any other graphing libs will build on echarts internals in the future and if the current rise in popularity will one day be seen as the end of d3.
- The documentation is truly best in class. Really great stuff. I've been trying to exactly emulate the behavior from our previous lib and while that's occasionally been challenging, the docs have always come through for me.
On a side note my current headache that I'm trying to solve with echarts is handling log scales with data that contains negative/zero values. Quite a few graph libraries that support log scaling don't support this, and I think it may have to do with some fundamental conflict between ui people who (imo reasonably) look at their data and say "my log scale Y axis ticks should be -1, -100, -10000, -1000000! Why is that so hard?" And some dev with a slightly puritanical bent thinks about log(0) and log(-100) and their eye starts twitching and in the end of the day the feature never gets added. I get it math nerds, I get it. But throw me a bone, will ya?
> it's not d3 based. ... I'm curious if any other graphing libs will build on echarts internals in the future and if the current rise in popularity will one day be seen as the end of d3.
I think your history is a bit muddled here, and it shows when you suggest "generalized" means "at least 8 charts".
The reason D3 has the adoption it does is due to not being a charting library. Charting libraries like Echarts come and go. Some have more or fewer of this or that, but they all suffer the same design limitation: because they don't provide a visual grammar that you can recombine at will, you're forever limited by the scope of the charts provided by your library.
Going from D3 to Echarts is like going from Rust to Excel: it's a good move if your team is more productive in that environment, but you need to have a sober understanding of what you're giving up.
I think my original description - a foundational lib for generalized graphing libs - is more accurate than this. I mean, d3 is literally not a programming language. It's written in js, and used in js (ignoring ts/coffeescript, etc). It's a library that provides a large toolbox of useful functions for drawing, and for the kinds of math one needs when implementing a broad array of charts. One builds on top of it, and IME it is _rarely_ directly used. d3 describes itself as '[a] JavaScript library for bespoke data visualization'.
In what ways is it, though? For instance, D3 offers looping constructs and facilities for control flow, so I'd conjecture it's Turing-complete.
> It's written in js
It's a slim minority of programming environments that are self-hosted. Most are in fact implemented in another language.
> used in js
This is a technique called "deep embedding" in the DSL literature.
> provides a large toolbox of useful functions
To put it simply, that's not the point of D3 at all. D3 provides a mental model for data applications that enables a developer to raise the level of abstraction. This is a new way of thinking about data flow in visual applications. Oh, and it also has some helpful maths included.
> One builds on top of it, and IME it is _rarely_ directly used.
I take issue with this comment from several angles. Facially it's untrue, there's clearly lots of examples of D3 development. And the implication that something is defined by the output of some of its users rather than the tools it offers them all seems a bit strange.
The difference between your "generalized graphing libs" and D3 is orders of magnitude larger than the difference between those libraries and one that only offers a single chart type.
D3 is a library that 1. lets one elegantly and concisely bind data to DOM elements 2. use elements’ data to control their appearance. This ends up being sufficient to be able to draw plots, but is much more general (you wouldn't call a `<ol></ol>` a chart, but D3 can add and remove `<li>`s from it with ease).
Matplotlib for python solves this with a SymLogScale, which is allows you to chart (-10 ^3, - 10^2,..., 10^2, 10^3) in the way that you'd expect. It does this by being linear between two small limits (to avoid doing log(0) and upsetting the mathmos) and showing sign(x) * log(abs(x)) elsewhere.
You can probably do the transformation yourself directly on your data, and then do the inverse transformation relatively easily for your tool tips.
> On a side note my current headache that I'm trying to solve with echarts is handling log scales with data that contains negative/zero values.
If dealing with log(0) is an issue, a simple solution is to add 1/0.1/0.01.. to all values in the sample. Pick a fraction that is within the margin of error for your calculations.
This is not supposed to be a blanket advice for everyone - use your judgement based on the use-case.
This gets less ideal when you want to implement some kind of hover tooltip that shows that value at a particular point. Then you need to figure out if that point is _really_ 0.001, or if it was actually 0 and you just swapped it with 0.001 so that your graph lib didn't puke. FWIW echarts lets you replace 0s with null or '', but that doesn't help with the negative values issue.
Edit: not disagreeing with you at all, just trying to make the situations where this might be problematic a bit more concrete.
> This gets less ideal when you want to implement some kind of hover tooltip that shows that value at a particular point.
A data value doesn't have to be identical with the value used for plotting purposes. Haven't used Apache Echarts but this separation of concerns is trivial in D3, for example.
This comment so beautifully distills the difference in philosophy between D3 and Echarts.
Charting libraries like Echarts provide a few stock visualizations and a handful of knobs to turn. If there's not a knob for the parameter you wish to adjust, you're out of luck.
D3 provides instead a visual grammar: a toolbox for building your own visualizations.
I'm curious about what you mean when you mention it not being "react friendly". I didn't encounter any issues when simply putting the chart creation in a useEffect hook (that calls the chart.dispose function in callback).
The solution you've mentioned - building your option object in an effect - is straightforward, but from my perspective very un-reacty. In some sense, the attributes in the option object will end up becoming various types of svg nodes. I can imagine that a more react-friendly implementation of e-charts would have components for each part of the option object. I also think echarts update process (setOption, merge/notMerge, etc) doesn't map very well to react's lifecycle concepts.
That said, none of this is a dealbreaker from my perspective. It's an awesome library and it's _generally_ a joy to work with in react. But there's a bit of friction and that's ok.
I would be interested how to move away from react. Either you write a lot of wrappers and not using the react-* libs at all and put in extra effor all way long, or it is quite hard, isn't it?
If you are generally interested in how to write components that can be used by many frontend libraries (react/vue, etc), you should take a look at https://github.com/microsoft/fast. I was tangentially involved with porting an existing component library to it and the end result was pretty framework agnostic and well made.
You need to become familiar with ShadowDOM if you are not already.
I am hopefully many years away from any such effort :)
But there are still things one can to do prepare, such as:
- cleanly separate as much of your state logic as possible into something like redux which isn't tied to react and can be used in many alternatives (svelte, solid, etc), which _increases_ but does not _guarantee_ that that logic will be reusable.
- choose ui component libraries that have implementations on top of multiple libraries. Many react apps today are built using mui, and there are similar (though less powerful) implementations of the underlying design system (material _design_, as opposed to material _ui_) for other frameworks. This at least cuts down on design work/decisions. If your webapp is going to (presumably easily) look the same before/after, you don't have to have a ton of design meetings to decide how different is too different. Notably this is the reason why I wanted to move from react-vis to echarts at my job: it was possible to transition with very little visual difference.
- Separate your data fetching logic out of react components. Implement a library for fetching data for your api, then implement a set of very light hooks/wrappers around that library, and then use those hooks/wrappers in your components. (note: this suggestion may be indistinguishable from 1) if fetching is very tightly tied to your store).
That may seem like a lot to do, but I think 1/3 at least are good ideas even if you plan on being on react for _forever_.
Most of what I wrote is based on preparing something like an SPA, and I'd imagine the considerations are very different from something that uses SSR. I'm personally not a fan of SSR, or at least the space I want to work in doesn't see any benefits from SSR, so that's not something I think about.
I'm currently migrating from echarts to D3. Once you get to rather complex charts the bugs show themselves. Sometimes you need the control that a low level library gives you.
Echarts works perfectly fine with responsive sizing but the developer does have to use it properly.
We used ECharts to build our charting library at Evidence and it’s been a great experience overall (https://evidence.dev).
We started with D3 and a few other tools, but felt that we get a lot more out of the box with ECharts, like interactivity and an events API. ECharts is also a lot more extensible than people give it credit for.
We're trialing ECharts on a couple dashboards at the moment and it's improved velocity a lot over previous D3-based approaches. This has been my experience in other companies too, where a purist developer will come along and start building yet another custom D3 solution which takes so long to deliver that the users just build a pipeline to dump the data and hack their own charts together in a different tool instead.
My feeling is that D3 just isn't worth it unless you are building a bespoke visualization for a unique dataset. For most everything else, ECharts is so much faster to deliver value to the users. The ease-of-use of ECharts reminds me of Highcharts back in the day, except it's free! I'm not sure it has a very strong support network behind it, but perhaps that will improve as more popular tools switch (Gitlab, Superset etc).
Yes, Evidence was my intro to ECharts. I’m more on the building datasets side of things lately, but on the occasions that I do need to produce some analyses Evidence is the model I want to use. Thank you.
Currently we are grappling with the need to create a GANTT CHART with a quirk: we want to minimize vertical space (for compact printing on paper) so tasks that do not have any overlapping dates should appear on same horizontal level.
Our team tried a few options and is now implementing something from scratch instead.
We also want text to be legible, dates and task names directly shown near the task bars, etc.
If there is a good open-source library that allows us to customize a gantt chart (for both display on a webpage and PDF/printing) with such quirky requirements, gthat would be a great time saver for us. Please provide any pointers you may have - Thanks!
> Our team tried a few options and is now implementing something from scratch instead.
>
> We also want text to be legible, dates and task names directly shown near the task bars, etc.
This is bin-packing with extra steps, which is famously NP-hard.
The Wikipedia page just shows a linear time algorithm for identification of an undirected graph as an interval graph. The article notes that there's a polynomial time algorithm for coloring, which is the task-line assignment analogous problem. Still, not NP-hard, but not linear either unless there's another resource that mentions otherwise.
The first paragraph mentions a linear time graph colouring algorithm. In fact further on they explain that a simple greedy algorithm that goes through the tasks in order of starting time will work. It's fairly easy to prove it does.
Maybe finding the optimal planning given some dependency is harder (though it isn't if you only have some simple requirements), but this is about visualising a Gantt chart, not calculating one.
Hi! I have tried all the gantt chart libraries, and also ended up building my own. The library isn’t open source (yet) but does this, as well as some other stuff around optimizing for print. Email in profile
While not open source have a look at dhtlmx gantt, after starting to integrate it you’ll come to realise the sheer amount of work to get a Gantt chart working how you mostly expect it to. There’s just so many little features that you need to implement it’s mind boggling.
Completely - they simplify the act of transforming data into visualizations down to the essential association of dimensions to axes/color/etc visualization concerns.
Visuals defined in JSON (so perfect for manipulation and generation) and also able to bake-in custom interactions within that is an awesome power.
I like the look of Observable Plot, but it doesn't do interaction like Vega/Vega-Lite. (They are working on some interaction though, and they have quite the team)
You need to know on what criteria the libraries are judged. Some people will judge most features = best, even if that means some string decoding library installs a 1500 other libraries so it can render PDFs of the strings it decoded and it installs a file system watcher so it can re-render them as they change. Me, I'd choose the library that just decodes and nothing else but plenty of devs want it to "do all the things"
Doesn't mean it's not fun/useful though! Stars are a kind of handwave proxy for utility. And it's useful to see what's catching fire and what's staying lit.
- [0] "The following graphs compare the number of stars added on GitHub over the last 12 months."
So link them and be helpful rather than mouth off. The links you provided are to GH star-based lists, and all the sub-lists on those pages are also star-based lists. I'm sure you're right, so I'm keen to see what you're talking about.
Is Superset extensible enough to click on the charts -- for example, click on part of the pie-chart and have it show the list that makes up the data for that part of the pie chart?
Thank you for this. I didn't know about Echarts and had just started working on a low maintenance replacement for Grafana for personal use. This might end up replacing my current charting library Plotly. It looks way better documented for someone new to the charting landscape.
- It's not very react friendly out of the box. There are some good wrappers that mostly fix this, and overall I view this as a strength as someday maybe the product I work on will migrate away from react. Our graph configuration may survive that migration assuming our next ui lib supports echarts in some fashion.
- it's not d3 based. This part is kind of a big deal. For those not familiar with the internals of js graphing, d3 has been a foundational lib for generalized graphing libs for a very long time ("generalized" here is meant to differentiate between something that can render 8 graph types versus a jquery plugin that can render only a bar chart). I'm curious if any other graphing libs will build on echarts internals in the future and if the current rise in popularity will one day be seen as the end of d3.
- The documentation is truly best in class. Really great stuff. I've been trying to exactly emulate the behavior from our previous lib and while that's occasionally been challenging, the docs have always come through for me.
On a side note my current headache that I'm trying to solve with echarts is handling log scales with data that contains negative/zero values. Quite a few graph libraries that support log scaling don't support this, and I think it may have to do with some fundamental conflict between ui people who (imo reasonably) look at their data and say "my log scale Y axis ticks should be -1, -100, -10000, -1000000! Why is that so hard?" And some dev with a slightly puritanical bent thinks about log(0) and log(-100) and their eye starts twitching and in the end of the day the feature never gets added. I get it math nerds, I get it. But throw me a bone, will ya?