Apache ECharts
262 comments
·April 8, 2025lucasfcosta
noduerme
I must've looked at this years ago, but for whatever reason, hitched my wagon to Chart.js and haven't really needed anything it couldn't do. And that's for weird one-off custom stuff. For business analytics I just self-host a Metabase server. I wish there were more visualization options with Metabase, but it's such a cinch to set up models and queries. But I don't often get a visualization request that justifies the time to create a custom chart.
jitbit
That, plus:
* Echarts is about the only dependency in our project that I can upgrade - and be sure it never breaks anything. It is so well-thought in that regard. Upgrading for 3.x to 5.x? Sure! "npm update" and everything just keeps working smoothly. That is so refreshing to see these days. Unbelievable.
* It's both SSR-friendly and SPA-friendly. Being mostly vanilla-js, works seamlessly with both react/vue/apline AND with old-school rails/asp.net/php/whatever. Our app is pretty classic SSR (https://www.jitbit.com/) and I can construct my chart's JSON object on a server using some linq-queries and provide that to echarts.
* ...OR I can give it a reactive object from vue-based SPA. Dun matter, it just works.
* whenever we have to add some workarounds (like, showing hovering labels on a pie chart with a bold percentages or something) - I never have to dig into their sources. Almost anything has already been figured out. Easily googlable and "LLM-able".
naught0
I recently had the need to create a gradient line chart with each step on the y-axis representing a color which should blend with its neighbors, and echarts was the only option that made sense to me after trying a few. The lack of obvious react integration initially put me off, but like any js lib it was pretty easy to use anyway. Echarts surprised me - it's great.
zurfer
I can't agree with that. eCharts is good, but https://plotly.com/javascript/ is also super nice and I am actively following https://observablehq.com/plot/ which seems on a path to true greatness.
ramonverse
Plotly is full of undocumented features. My guess is because they have an entire consulting business helping devs with this
incoming1211
plotly... please... I hope I never have to touch that again, the documentation is so bad. It's not on the same level as eCharts.
disgruntledphd2
Yeah, agreed.
I particularly "like" the way they have multiple APIs and inconsistent examples across them. Would it kill you to have the same examples in each?
That being said, i generally like the library but the docs are bad.
zwnow
How is it better than Chart.js? Im curious as the implementations look extremely similar.
anentropic
One consideration I looked at when choosing between them was I believe chart.js is Canvas-only, whereas ECharts can output SVG
for millions of points maybe Canvas rendering is more performant
but for simple charts SVG provides an easier way to get responsive sizing just via CSS without involving JS to re-render
zwnow
Hmm I see, will try the apache one, thanks for the input
stuartaxelowen
Did you compare to vega/vega lite? Curious to hear how they compared!
spaceribs
I've used both, and while I think Vega has it's uses, it's not nearly as web developer friendly. Frontend engineers want a clear delineation between logic, composition and styling. By combining everything into a JSON document, you sacrifice that developer experience while introducing a lot of bespoke approaches.
That said, I absolutely love the idea that a blob of JSON living in my database contains everything I need for my visualization. The reality is that not enough other people are willing to put in the effort to learn that syntax, making it somewhat of a selfish tech choice.
RobinL
As a big user of vega lite I think that's fair. I think it really shines when used by data vis experts, where charts need to be precise, such as in research and analysis contexts. For something like a simple a metrics dashboard I think I'd agree that it may be difficult for devs.
adeptima
same experience
neomantra
I'll toss some props to `go-echarts` [1], which allows you to declare charts with Golang types and it all gets bound to JSON automagically by Golang's JSON marshaller. I've used it for many projects and whenever there's an issue/PR, the maintainer responds quickly.
It's fun to Go-embed JavaScript functions and SQL queries, for this weird blend of data, SQL, Go and Javascript. Here's a Golang example that pulls data from a DuckDB and creates a baked-in candlestick chart file with JavaScript tooltips. [2]
[1] https://github.com/go-echarts/go-echarts
[2] https://github.com/NimbleMarkets/dbn-duckduck-goose/blob/mai...
TheGoodBarn
This is so sick thank you for sharing. I do a lot of Go + DuckDB stuff. I’ve done some janky JS / html/template stuff for charting so this will be fun to play with
rochak
Now that’s incredible
selfhoster
[flagged]
rorylaitila
ECharts is in my opinion the best out there. It surprisingly doesn't come up in a lot of lists or search for charting libraries. I've tried them all: chart.js, google charts, amCharts, Highcharts, ApexCharts. We use it in our tool/library https://docs.chartsql.com/
eigenvalue
I think that’s because it’s a Chinese Project. Same thing with Ant Design Components, which are really awesome but not as well known as they should be.
sdesol
I think it being Chinese is part of the reason as some of the examples in the early days were Chinese only, which could deter some people. It is certainly more complex (for a good reason in my opinion), I can see why it is not well known since I think the vast majority just wants to create simple charts. However, with echarts, it really can meet Enterprise needs.
rorylaitila
Yeah that might be why. A couple years ago I was trying to find "this cool charting library" I came across and I could not get it to surface in Google.
ranger_danger
A large number of developers/users of Apache ECharts also seem to be Chinese.
nchmy
Link here, for reference. https://github.com/antvis
It seems good, but their docs websites are absolute trash (though they've seemingly gotten somewhat better recently - they were previously completely unusable).
e.g https://g6.antv.antgroup.com/
Overall, I think you cant go wrong with Apache.
hamsterbase
There's one more thing. Leader of antv is the developer of echarts.
RowanH
Oooo thank you for mentioning that. Looks quite feature rich !
athrowaway3z
Time to put on a conspiracy hat.
If you scroll down, the entire comment section reads a lot like a campaign to fix their search results & AI suggestibility.
Way too many comments read like generic seller-inserted reviews, eg "Great Product!", "Tried X, Y, Z but this solved my problem!".
abirch
What about D3js? I know that D3js is low level, but with AI it's pretty easy.
infecto
I refuse to use it out of principle that they have intertwined it with observable. All the modern docs for d3 assume you are using observable. So unless you are relying entirely on AI it’s now even harder to grok the documentation.
Not sure why this is so contentious. You can search online how many others this impacted as well. All of the modern examples for d3 were rebaked into the observable notebook pattern and it seriously obfuscated how to use d3 itself.
dleeftink
There's Plot, which is as standalone as anything[0]. That said, I still find D3 unparalleled in depth and scope.
kowlo
It's a shame - and I'm not sure why they did it other than to use D3.js' popularity promote Observable.
the_real_cher
When did Observable get their hands on D3?
Last time I looked at D3 a half decade or so ago I thought it was an open source lib?
jwilber
This is a very bizarre take. If you want to just blindly copy and paste d3 code, you may have issues with the docs being hosted on observable. But absolutely zero part of the d3 api (or core design patterns of use) have anything to do with observable.
It’s like saying, “I refuse to use PyTorch because their docs are built with mkdocs.”
Moreover, even if the coupling were limiting (which, again, it is not), it’s odd to attack observable since everything they put out is fully open-source. It’s not like they’re hiding docs behind a paywall, they’re actively contributing to the viz ecosystem through basically everything they release (eg Observable Plot, Observable framework).
As far as echarts goes, it’s a great tool. The declarative syntax for charting always feels a bit odd, but it’s easy enough to wrap into component libraries. AFAIK it still powers many of the big BI viz tools used today (eg AWS Quicksight).
rorylaitila
We needed charting for ad-hoc business reporting from SQL. ECharts was at the right level of ease of use and available charts, interactive, and looks great right out of the box.
kowlo
Not touching D3.js since Observable.
smelendez
Depends on the use case.
If you’re a data viz team and do this all the time, and everyone knows or is willing to learn D3, then sure. Otherwise, if you just need to add a graph to your website, you may find it slows you down and makes code less maintainable.
I personally find it confusing and as others mentioned I can forget how it works over time, though I admire it. I don’t think I could jump in and edit D3 code today without careful study, any more than I could jump in and edit Perl code. Echarts/Highcharts etc. are much more intuitive.
null
ActVen
I used to love using it. But, all of my coworkers hated it. I haven't revisited since the AI boom. Maybe it will have a bit of a comeback. Many people found it too difficult.
hajile
I'm a big fan of VisX for the level of control it gives.
chamomeal
I love visx! Surprised to see your comment is the only mention of it here.
I guess it’s specifically a react library, but it’s such a sweet spot of control and built-in convenience. Having all the annoying stuff like curves/axes/scales/shapes handed to you in a pretty un-opinionated way is really nice.
I was at a startup for a few years and I built all of our client’s dashboards in visx. I loved it from the first minute to the last, and have almost no complaints. And there are few few libraries I can say that about!
TN1ck
Can recommend visx as well, it's great as it's basically a thin layer around d3, giving you maximum flexibility while providing lots of built in components to get you started.
rorylaitila
VisX looks nice. We haven't had the need for more complicated visualizations yet but I'm always looking out for options.
bezbac
I can second this. VisX will be a little more effort but it will let you build anything you could build using d3.
RedShift1
I like Plotly.
rorylaitila
I took a look at Plotly but ultimately wanted a Js solution for our Java backend, so that we can run our SQL charts layer on GraalVM.
skeeterbug
They publish plotly.js and react bindings as well.
evaneykelen
After many trials with other libraries, my team settled on Apache ECharts last year, and we do not regret it: excellent documentation, performant, highly configurable yet easy to use, and supporting all the chart types we need (bars, stacked bars, maps, zoomable/scrollable time series, and scatter plots).
nXqd
how is it compared to ag-grid chart?
FredPret
The line race looks so cool.
https://echarts.apache.org/examples/en/editor.html?c=line-ra...
Toggle the switches to trigger the race. By the way, well done Norway.
NicuCalcea
It looks neat, but unlike the Hans Rosling example someone else mentioned, the animation adds no additional information. Showing just the last frame would get the same point across much quicker and more accessible. It's a form of chartjunk.
razemio
You know how a presenter asks questions on a topic where he is the expert? Same goes for this animation. It does not show but hide information to keep the reader engaged. I found myself guessing who will be first and boy was I wrong. My ego would have prevented me from noticing, if the chart would have been presented to me right away.
On YouTube you can see how well this works. There are channels with a huge follower base just existing because of this animation.
noduerme
Not completely unrelated, the mechanical horse race game that used to be at The D in Vegas, and now is at the Linq (I think?) has a similar effect on the human psyche. As does gambling on most sporting events. Anything with a lot of ups and downs. I really started to think about this when I was developing casino games about 15 years ago. But the same is true with any game, or any future event. When an outcome is unknown, we experience time as a set of discrete emotional peaks and valleys - we experience an extra dimension of time, the high/low. Apart from being a highly successful design hook, I think it can be a really powerful way to encode information. Especially if you have time-referenced data and you've already exhausted the other axes or relative sizes you might use to convey your dimensions. Like, my main argument with using that "race" is that you could use the x-axis for something else, and have the whole graph change over time.
But you're very right that this indeed relies on an emotional component to achieve the full effect of conveying time in two dimensions. If there's no emotional attachment to the outcome, our brains don't process the highs or lows. In that case, a variance chart like open/close prices on the stock market might work better.
kortilla
These channels don’t exist because it’s a better way to display information. It’s a more click bait way.
A chart that works that way is the title equivalent of “you won’t guess who wins”.
I get sucked into those “X over 50 years videos” and watch to the end to get the satisfaction. But it doesn’t help me remember the outcome at all.
It’s just engagement bait in video form. A chart on a webpage like this is just chart junk like the poster said unless it’s actually updating in real time.
NiloCK
At the risk of piling on (others have commented), I'll go so far as to say that there really is more information here if you make the gentle assumption of a human observer.
In the animated version, a human observer here is allowed (forced) to occupy mental states of a real-time observer. They have the experience of "X has jumped ahead - I wonder if it'll last - oh, wow, Y is really surging".
The visceral experience matters, and is impossible to recreate post-hoc if all of the info is presented up front.
(edit: "more information" in so far is it informs more - leaves more impressions on the observer)
FredPret
1. The race animation adds no information, but better communicates the idea that we're looking at a series of moments in time, each with its own history and emotional impact. Watching the lines race shows us what it would've felt like looking at this graph during each year.
2. The Chartjunk wiki cites Adolf Loos's idea "ornamentation is a crime". But I think we're done with modern minimalism and in the process of rediscovering the joy in ornamentation. This is an aesthetic choice and you may disagree.
bjarneh
> the animation adds no additional information.
No it removes information; to be able to focus on one period at a time as it evolves.
Seeing a "living graph" of how something evolves is different than seeing the graph fully drawn statically, that cannot be considered chart junk IMO.
helloplanets
Following the parent comment's idea, it'd end up in a table being the best choice 100% of the time.
Because the underlying assumption is that accessibility and the ability to grasp the data that is being conveyed isn't completely dependent on the audience. If I happen to prefer a static chart, an animated chart might still convey the intended thing in a stickier way, to a wider audience.
dijksterhuis
it would get the point across much faster. but it would be a less enjoyable interaction. this is an example graph that i'm never going to look at ever again. i don't even need to care about information. like, it's mostly irrelevant to me. it's a toy example. and it's a bit of a fun example to make people go 'huh, this is a cool vizualisation package'.
if i had a dashboard i needed to use at work set up like that i'd have a bloody conniption after a week. but this isn't a work dashboard -- it's a functionality demo and i'm more likely to remember echarts now as a result (purpose of examples achieved).
null
rrr_oh_man
Props to Hans Rosling I think:
vecinu
Something's off here. The data appears as "life-expectancy-table.json" but the title refers to Income. Not sure where the mistake is.
macNchz
The source data, despite the filename, contains Income, Life Expectancy, and Population by Country+Year: https://echarts.apache.org/examples/data/asset/data/life-exp...
gadders
>>By the way, well done Norway.
I wonder how well it correlates with the oil price.
simlevesque
If you're looking for a chart library for a web client, I also recommend charts.css. It's a godsend honestly, the concept is way simpler than most charts libraries and can achieve the same thing. Makes it so simple to use the old way, server side rendering, htmx, etc...
paulirish
In the same vein, I've long had a soft-spot for the JS-enhanced https://pancake-charts.surge.sh/ (developed by NYT graphics team and used for the covid charts).
tkcranny
Thought that felt very “Svelte-like”. And of course, turns out it was by Rich Harris himself back when he was at the NYT.
Beautiful charts, shame it looks defunct now.
infecto
Chart css is like any of the other numerous libraries that can draw a line chart. It is a world apart from echarts.
homebrewer
> can achieve the same thing
Did you even look at echarts demos, or amcharts demos for that matter -- it's basically the same thing, but paid for: https://www.amcharts.com/demos ?
I don't have anything against charts.css, but it's like comparing a children's plastic toy to a real space shuttle. I spend most of my work hours developing a heavy business analytics application (not unlike Apache Superset), and it would simply be impossible to implement it with something like chart.css
anentropic
While I agree with other replies that ECharts provides a lot more functionality than this lib, it does look very nice the way it transforms a semantic table of data into the chart!
I'm using ECharts (and happy with it) but there are some places where I want like a sparkline in every row of a data table, which is a lot of ECharts instances to instantiate, and this lib looks like it'd be great for that.
Eduard
The animation examples for chartscss are annoying. it doesn't look nearly as functional
didip
The biggest problem with this is that you are representing points in DOM, just like SVG.
If there are a huge number of datapoints, this library will paint itself in the corner.
miiiiiike
I’d keep it.
Announcement: “ECharts, a JS charts package” My assumption: It’ll be unmaintained within a year.
Announcement: “Apache ECharts, a JS charts package” My assumption: It’ll be maintained next year.
captainmuon
Interesting, I have the opposite association. When I see Apache something, I assume development has ceased and the project is legacy or maintenance only. There is a saying, "Apache is where projects go to die".
WilTheFarmer
I have not heard that saying before... as of 10 April 2025 W3Techs.com rankings Nginx - 33.8% Apache - 26.4% Cloudflare Server - 23.4% LiteSpeed - 14.7% Node.js - 4.3% Microsoft-IIS - 4.0% Envoy - 1.3% Google Servers - 0.8% Caddy - 0.3% IdeaWebServer - 0.1% Percentages of websites using various web servers Note: a website may use more than one web server
5 months using Apache Echarts and watch GitHub repository https://github.com/apache/echarts for all activities. The developer team enthusiasm and unity is impressive. It is flexible, powerful, constantly improved and plenty of examples.
captainmuon
It's not about the Apache web server, and I know there are a lot of actively maintained and respected projects under the Apache label (Lucene, Tomcat, Maven, ...).
I think the project that gave the most sour association was OpenOffice, which was donated to Apache when it was already over and the LibreOffice fork was well underway, and it has been on life support ever since. I recall there were a couple other projects with a similar fate but to be honest it is probably more of a brand reputation thing than an assessment of the quality of every project.
KomoD
> as of 10 April 2025 W3Techs.com rankings Nginx - 33.8% Apache - 26.4% Cloudflare Server - 23.4% LiteSpeed - 14.7% Node.js - 4.3% Microsoft-IIS - 4.0% Envoy - 1.3% Google Servers - 0.8% Caddy - 0.3% IdeaWebServer - 0.1% Percentages of websites using various web servers Note: a website may use more than one web server
How is any of that relevant to parent? People using something doesn't mean it's maintained. (I'm not saying it's not maintained, I just don't see how those numbers are relevant)
pavish
Glad to see Echarts getting the recognition it deserves. It is arguably the best open-source visualization library out there.
Here are some points others haven't mentioned:
(a) Uses canvas by default. Faster than any other library I've used.
(b) Extremely flexible. Want to write your own widget on top of the graphs (eg., a customized tooltip). Possible!
(c) Provides a lot of metadata. Want to get the position of a point in the rendered chart, to use in your code? Entirely possible!
(d) Works really well when importing into legacy web apps. They even provide an option to get a customized build on their site.
(e) Very good at handling streamed data. The animation is very smooth between data changes.
I've been using it for almost 7 years now for various production and personal projects, and it's still my go-to library. Their docs have come a long way since then.
They do have long standing bugs that get annoying, e.g, dealing with 0 when using log scales, provided there are workarounds for it. I haven't noticed any blocking bugs for most common usecases.
pb060
> Glad to see Echarts getting the recognition it deserves.
Why is it so rarely mentioned in chart libraries comparisons? Its not even listed on the Wikipedia page for JavaScript chart libraries. I discovered it by chance through Apache Superset.
JacobiX
In a quick web demo, this library was the only one that could handle interactive viewing and manipulation of a very large graph using its GraphGL component ! I don’t think it's a well-known visualization library, but it's quite interesting ...
smjburton
I was just looking into charting libraries for React/React Native, and Apache ECharts seems like a great contender for cross-platform data visualization. The libraries that I came across - react-echarts (https://github.com/hugocxl/react-echarts) and react-native-echarts (https://github.com/wuba/react-native-echarts) - both seem to be actively developed, and the fact that it's under Apache is a huge plus for future development prospects and maintenance of the project.
lucb1e
Noticed it uses HTML5 canvas to render data by default. To screen readers, am I correct in understanding that this is equally accessible as when people share screenshots of text?
There is an SVG option that looks identical but it doesn't say when you're supposed to use that, or why canvas exists (and is the default) if SVG would work equally well. Then again, setting an example chart to use SVG rendering (I was looking at the basic scatter plot functionality, since I use that most often), I can't seem to tab or otherwise navigate through the data points, so it may just be impossible to get the data read out to you like "first data point, year 2006 students 25 939" (if the axes were labeled "year" and "students", for example; they're not labeled in the example but it could still read out the positions of the points)
buovjaga
I see there are unaddressed requests for improving accessibility:
[Bug] ECharts claims to be accessible, but is not keyboard accessible https://github.com/apache/echarts/issues/18585
[Feature] Support for accessibility of elements inside the chart (series, legend...) https://github.com/apache/echarts/issues/18256
didip
You are asking why Canvas? The answer is simple: Canvas is vastly better performing when given a large amount of datapoints. The difference is not even on the same plane.
potamic
Is it even possible to make a chart accessible? I would have thought you would want to hide the chart and expose the raw table to screen readers.
mceoin
We [1] just added to ECharts as a charting library for our AI and are switching the default GUI charts over to it as well. We did a pretty extensive review before selecting it. ECharts won because it's excellent, and very pretty.
We've tested almost every visualization library under the sun when building Briefer (https://briefer.cloud) and I can confidently say that Apache ECharts is the best.
The main issues with other libraries is that they're either:
(a) ugly (b) difficult to use (i.e. having to do things imperatively) (c) not flexible enough
Apache ECharts solve these 3 problems. It's pretty by default, it allows us to mount/calculate the declarative spec for the graphs in the back-end and then only send the desired spec to the front-end so it can render, and it's also extremely flexible to the point we can support everything that traditional BI tools can do.
We've never had to extend the lib to do anything new, everything we need is already there.
Glad to see this great piece of work on top of HN.