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.
* 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".
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.
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.
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.
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]
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
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/
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.
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.
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.
It seems good, but their docs websites are absolute trash (though they've seemingly gotten somewhat better recently - they were previously completely unusable).
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.
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.
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.
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.
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!
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.
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).
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.
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.
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)
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.
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).
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...
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).
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
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.
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".
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.
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.
> 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.
Readit News
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.
* 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".
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
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.
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...
Dead Comment
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.
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!".
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.
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.
Deleted Comment
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!
https://echarts.apache.org/examples/en/editor.html?c=line-ra...
Toggle the switches to trigger the race. By the way, well done Norway.
https://en.wikipedia.org/wiki/Chartjunk
On YouTube you can see how well this works. There are channels with a huge follower base just existing because of this animation.
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)
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.
https://en.wikipedia.org/wiki/Ornament_and_Crime
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.
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).
Deleted Comment
https://www.youtube.com/watch?v=hVimVzgtD6w (2003)
I wonder how well it correlates with the oil price.
https://chartscss.org/
Beautiful charts, shame it looks defunct now.
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
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.
If there are a huge number of datapoints, this library will paint itself in the corner.
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.
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.
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.
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.