9 ms·

A love letter to Apache Echarts

166 points by zer0tonin 3y ago

folli 3y ago
As someone who sank countless hours into D3.js with its steep learning curve, I appreciate the simplicity of Echarts. 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.
- Ringz 3y ago
  Seems to be a problem of that particular website. The examples[1] of ECharts work fine. [1] https://echarts.apache.org/examples/en/index.html#chart-type-line https://echarts.apache.org/examples/en/index.html#chart-type...
- cmoski 3y ago
  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.
fellowniusmonk 3y ago
Echarts has been amazing for awhile, I replaced all my highcharts and most of my D3 usage with it years ago (before it became an apache project.) I always assumed it didn't have more adoption because the docs weren't in English for a long time.
Octoth0rpe 3y ago
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?
- szundi 3y ago
  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?
  - Octoth0rpe 3y ago
    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.
  - jupp0r 3y ago
    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 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.
android521 3y ago
There needs to be directory of curated high quality libraries. It is very hard to filter through the noice.
- nox101 3y ago
  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"
- Octoth0rpe 3y ago
  Have you tried looked through the 'awesome' pages on github? https://github.com/topics/awesome https://github.com/topics/awesome
- jeanlucas 3y ago
  There is, here you go: https://bestofjs.org/ https://bestofjs.org/
  - popcorncowboy 3y ago
    This is a "Hot 100" style list, useful only for finding what's popular. There is no quality metric here.
    - jeanlucas 3y ago
      You should give it a try. There are quality lists, and even a hand picked annual list: https://risingstars.js.org/2023/en https://risingstars.js.org/2023/en It is not only based on popularity.
      - popcorncowboy 3y ago
        > 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."
albert_e 3y ago
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!
- RowanH 3y ago
  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.
- jxf 3y ago
  > 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.
  - shiandow 3y ago
    I think it's closer to graph colouring. And not the general version either. Apparently for such an interval graph linear time algorithms exist. [1] [1]: https://en.m.wikipedia.org/wiki/Interval_graph https://en.m.wikipedia.org/wiki/Interval_graph
    - disattention 3y ago
      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.
shdh 3y ago
I’ve been using e-charts for a couple years now, works great!
zxspectrum1982 3y ago
Ant Charts are also excellent and provide even diagrams https://ant-design-charts.antgroup.com/en/ https://ant-design-charts.antgroup.com/en/
- j-a-a-p 3y ago
  I just moved out ant charts for echarts. Too many bugs IMHO in ant charts (ant.design however is great).
- hamsterbase 3y ago
  Ant Charts was actually developed by the author of echats.
hackandthink 3y ago
Apache Superset is the easiest way to start with Echarts.
- Omnipresent 3y ago
  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?
  - hackandthink 3y ago
    https://preset.io/blog/drill-down-and-drill-by/ https://preset.io/blog/drill-down-and-drill-by/ (your user needs "can samples" permission)
MikeOfAu 3y ago
Surprising to me that Vega and Vegalite don't get a lot more love
- stuartaxelowen 3y ago
  Completely - they simplify the act of transforming data into visualizations down to the essential association of dimensions to axes/color/etc visualization concerns.
- dndn1 3y ago
  Absolutely with you. 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)
downsplat 3y ago
Is Chart.js officially out of fashion? Been using it for years with good results... My charting needs are admittedly not very complicated.
hughess 3y ago
We used ECharts to build our charting library at Evidence and it’s been a great experience overall (https://evidence.dev 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. 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 https://github.com/evidence-dev/evidence/issues/136
- Jgrubb 3y ago
  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.
- alisonatwork 3y ago
  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).
zaphar 3y ago
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.
ekianjo 3y ago
You can also use Apache Echarts through R with this package: https://echarts4r.john-coene.com/ https://echarts4r.john-coene.com/
ringofchaos 3y ago
I tried at least 5 Charting Libraries before settling for Echarts. 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 .

166 points by zer0tonin 3y ago

As someone who sank countless hours into D3.js with its steep learning curve, I appreciate the simplicity of Echarts. 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.

Ringz 3y ago
Seems to be a problem of that particular website. The examples[1] of ECharts work fine. [1] https://echarts.apache.org/examples/en/index.html#chart-type-line https://echarts.apache.org/examples/en/index.html#chart-type...
cmoski 3y ago
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.

fellowniusmonk 3y ago

Echarts has been amazing for awhile, I replaced all my highcharts and most of my D3 usage with it years ago (before it became an apache project.) I always assumed it didn't have more adoption because the docs weren't in English for a long time.

Octoth0rpe 3y ago

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?

szundi 3y ago
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?
- Octoth0rpe 3y ago
  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.
- jupp0r 3y ago
  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 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.

android521 3y ago

There needs to be directory of curated high quality libraries. It is very hard to filter through the noice.

nox101 3y ago
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"
Octoth0rpe 3y ago
Have you tried looked through the 'awesome' pages on github? https://github.com/topics/awesome https://github.com/topics/awesome
jeanlucas 3y ago
There is, here you go: https://bestofjs.org/ https://bestofjs.org/
- popcorncowboy 3y ago
  This is a "Hot 100" style list, useful only for finding what's popular. There is no quality metric here.
  - jeanlucas 3y ago
    You should give it a try. There are quality lists, and even a hand picked annual list: https://risingstars.js.org/2023/en https://risingstars.js.org/2023/en It is not only based on popularity.
    - popcorncowboy 3y ago
      > 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."

albert_e 3y ago

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!

RowanH 3y ago
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.
jxf 3y ago
> 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.
- shiandow 3y ago
  I think it's closer to graph colouring. And not the general version either. Apparently for such an interval graph linear time algorithms exist. [1] [1]: https://en.m.wikipedia.org/wiki/Interval_graph https://en.m.wikipedia.org/wiki/Interval_graph
  - disattention 3y ago
    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.

shdh 3y ago

I’ve been using e-charts for a couple years now, works great!

zxspectrum1982 3y ago

Ant Charts are also excellent and provide even diagrams https://ant-design-charts.antgroup.com/en/ https://ant-design-charts.antgroup.com/en/

j-a-a-p 3y ago
I just moved out ant charts for echarts. Too many bugs IMHO in ant charts (ant.design however is great).
hamsterbase 3y ago
Ant Charts was actually developed by the author of echats.

hackandthink 3y ago

Apache Superset is the easiest way to start with Echarts.

Omnipresent 3y ago
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?
- hackandthink 3y ago
  https://preset.io/blog/drill-down-and-drill-by/ https://preset.io/blog/drill-down-and-drill-by/ (your user needs "can samples" permission)

MikeOfAu 3y ago

Surprising to me that Vega and Vegalite don't get a lot more love

stuartaxelowen 3y ago
Completely - they simplify the act of transforming data into visualizations down to the essential association of dimensions to axes/color/etc visualization concerns.
dndn1 3y ago
Absolutely with you. 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)

downsplat 3y ago

Is Chart.js officially out of fashion? Been using it for years with good results... My charting needs are admittedly not very complicated.

hughess 3y ago

We used ECharts to build our charting library at Evidence and it’s been a great experience overall (https://evidence.dev 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. 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 https://github.com/evidence-dev/evidence/issues/136

Jgrubb 3y ago
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.
alisonatwork 3y ago
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).

zaphar 3y ago

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.

ekianjo 3y ago

You can also use Apache Echarts through R with this package: https://echarts4r.john-coene.com/ https://echarts4r.john-coene.com/

ringofchaos 3y ago

I tried at least 5 Charting Libraries before settling for Echarts. 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 .