A love letter to Apache Echarts
alicegg.tech
alicegg.tech
- 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?
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.
Okay, then what is it? A more general tool/framework to implement actual charts?
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.
You can probably do the transformation yourself directly on your data, and then do the inverse transformation relatively easily for your tool tips.
https://matplotlib.org/stable/api/scale_api.html#matplotlib....
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.
Edit: not disagreeing with you at all, just trying to make the situations where this might be problematic a bit more concrete.
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.
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.
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.
You need to become familiar with ShadowDOM if you are not already.
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.
On the other hand, looking at how the charts in the post overflow the margin on mobile shows that it's still not as simple as needed.
[1] https://echarts.apache.org/examples/en/index.html#chart-type...
Echarts works perfectly fine with responsive sizing but the developer does have to use it properly.
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.
If anyone is curious, we documented the process of selecting a charting library after assessing several options: https://github.com/evidence-dev/evidence/issues/136
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).
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!
This is bin-packing with extra steps, which is famously NP-hard.
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.
[1] https://github.com/neuronetio/gantt-schedule-timeline-calend...
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)
I always assumed it didn't have more adoption because the docs weren't in English for a long time.
It is not only based on popularity.
Except it literally is? [0]
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."
(your user needs "can samples" permission)
I used it with React. My app is mostly financial data simulation and analysis and echarts fit the need
The documentation is great and with some tweaking you can make it look great. The customizing options are quite good.
I prefer it to some react only charting libraries .