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.
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.
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.
I used Plot for an academic paper I wrote recently. It was the only charting library that I found that let me generate the charts I wanted to draw - which in my case was a grouped bar chart with a logarithmic scale. Ie:
I reckon you can get something quite similar with matplotlib without too much trouble, though that strongly depends on how comfortable or familiar you are with it.
Past few years but I don’t have a timeline handy. I am probably ignoring important details but Mike Bostock cofounded observable maybe 4-5 years ago? So for all intents and purposes they have always been the same crew but they made a conscious decision to tightly intertwine d3 docs with observable notebooks.
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).
Look, it’s not “bizarre” to point out that Observable has deeply shaped the modern D3 ecosystem. The issue isn’t that the D3 API has changed, it’s that a huge number of learning resources, examples, and docs have been rebaked into Observable’s reactive notebook style, which, for people not using Observable, adds a ton of indirection and mental overhead.
You might not notice it if you already know D3 inside and out, but for newcomers, it’s a bit of a turnoff. It’s ok if you like it though!
And no, this isn’t about “blindly copying and pasting.” It’s about people wanting to use D3 without having to learn an entirely different execution environment. That’s a reasonable boundary to set, especially when time and focus are finite.
You can use as many italics as you want but I don’t think it’s a wildly bold claim and your counter example is simply silly.
Pre-observable, I used d3 to develop a very complex visualization with real-time updates. It was difficult because d3 has a lot well-thought-out-but-complex concepts, but the docs and examples helped me fully understand how it worked, and the result turned out spectacular.
A few years later, I needed to build a simple novel visualization. A major new version of d3 had come out, and all the examples and documentation got Observable-ified.
Enough time had passed that I could only vaguely recall some of the original concepts, so I set out to re-learn. YMMV but, for me, it was impenetrable. With the limited time I had, I just couldn’t figure out how to untangle d3 from observable. I gave up. Very sad.
I'm an experienced dev and looked seriously into D3 some month ago for the first time. I can confirm what you wrote. The notebooks feel like an unnecessary hurdle. It's not a big hurdle, but one that could be avoided so a slightly annoying experience.
"You can use as many italics as you want but I don’t think it’s a wildly bold claim and your counter example is simply silly."
I don't understand the relevance of any of this, but I think I've done a fair job outlining my points above. Let me give my best summary: the execution environment used by a library's (example) documentation is independent from learning the API of the library itself. I agree that newcomers to JavaScript may find plenty of confusion there, and I'm sure a decent chunk of D3's users may be new to web-programming in general, but it's not the job of D3 maintainers to account for that.
I actually think our back-and-forth is a perfect example of why open-source is so painful to work on.
D3 is one of the best documented libraries out there is. There are multiple books, hundreds of hours of youtube videos, and most importantly, dedicated maintainers
(Mike Bostock, Philippe Riviere, etc.) who've poured hours into additional sources of documentation and are very responsive on GitHub issues.
The unfortunate outcome here is that users have come to expect this sort of high-quality support and documentation (again with the italics, who does this guy think he is???). Every D3 submodule has standard api documentation, sure, but thats expected of all libraries these days. However, the additional example documentation (again, nobody got paid to make this material) for the most recent releases has been migrated from bl.ocks.org (a now defunct open-source service users didn't pay for it) to Observable Notebooks. Now, Observable is a VC-backed business, yes, but the documentation is still completely free. In this thread, you mention you don't like this, so in at least one online conversation where D3 comes up, you actively advocate against using it out of principle! (Couldn't resist!).
Of course this is just my viewpoint on what has transpired, and I'm likely articulating it in a more-inflammatory-than-reality manner. But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all. Even more so if it helps out the authors of the open-source library.
As a tip for those who have difficulties going from the reactive Observable model to vanilla js -> you can always just take an observable notebook and ask AI to convert it to a set of vanilla files for you.
Appreciate the lengthy response, but I want to clarify a few things since I think my original point keeps getting mischaracterized.
First, the italics. You opened with “This is a very bizarre take”—emphasis on very—which, whether you intended it or not, sets a smug tone. It’s the kind of rhetorical move that shuts down discussion before it starts. I’m not saying this to nitpick style, but to point out how quickly this moved from a discussion about tooling to a dismissal of my viewpoint. It is an easy tell the person writing gives away when they use it like you do.
Now, to the substance: yes, the D3 API is technically independent of Observable. But in practice, Observable is now the primary medium through which new users encounter and learn D3. The official examples, new documentation, and most teaching material are embedded in the Observable environment, which introduces its own model of reactivity, syntax, and execution. That’s not a minor detail, it’s a real obstacle for people who just want to understand and use D3 in plain JavaScript.
Your PyTorch/mkdocs analogy completely misses the mark. Mkdocs is a static site generator. It doesn’t change the code you’re learning—Observable, on the other hand, does. You can’t meaningfully learn D3 from many of these new examples without understanding how Observable cells work. That’s a tight coupling, and one I don’t think should be hand-waved away.
“Just use AI to convert the notebook” is a non-answer. It assumes everyone is okay with outsourcing understanding to a black box just to get a usable snippet. That’s exactly the kind of indirection I’m objecting to in the first place.
Lastly, yes, I’ve set a personal boundary: I don’t want to buy into an ecosystem that made a choice I don’t support. That’s not a call to boycott, it’s just me saying, this direction doesn’t work for me. If that’s enough to dismiss my view as bizarre, then I’m not sure what kind of discussion is even possible here.
> But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all
This is the core point. Yes of course the existing d3js docs are better than nothing. That isn't the complaint. The complaint is the current docs are significantly worse than older d3js docs that weren't notebook-based.
Can you provide an example? I’ve been using d3 on-and-off for almost 10 years, and the core docs have just gone from README’s to static-hosted pages with the same (version-specific) content (eg https://d3js.org/d3-selection/selecting). What is significantly worse here between the two? To my eyes, they’re basically identical: https://github.com/d3/d3-selection/tree/86
My best guess is that you’re referring to bl.ocks.org, which hosted d3 examples as standalone html examples, but this was independent from the d3 docs.
The issue isn’t that the API documentation has disappeared, it’s that the learning experience for newcomers has degraded. The Observable-first direction has made it significantly harder for new users to grok D3 without buying into an entirely new runtime and mental model. Yes, the docs are technically still there, but they’re increasingly fragmented, and many examples now assume you’re using Observable or some variation of its reactive notebook model.
Bl.ocks.org wasn’t officially part of the D3 docs, but it played a critical role: it was the on-ramp. People learned by tweaking examples, not by reading method signatures in isolation. Saying people just want to “copy-paste” kind of misses the point, examples are how many developers build actual understanding. They’re not just blindly pasting code; they’re reverse-engineering patterns, figuring out how the pieces fit together.
We get it — you enjoy the library. But many users don’t appreciate the direction it’s taken. Such a bizarre defense. I guess we are not supposed to look at the examples when trying to grok a new library, especially a library for chart visualizations which is historically not known to be the easiest to work with.
Ah, the good old "you’re not allowed to criticise open source projects, because they’re open source!"
Observable is cool when you want to build data notebooks. Observable is obnoxious if you want to add a D3 pie chart to your Vue application and have to untangle calls to D3’s API from reactive cell values, which look like ordinary JavaScript, but are not, and will cause compilation and runtime errors when copied.
The problem is that D3 resources mix D3 documentation with demos of D3 itself, and demos of Observable, into a single, inseparable combination. Nobody would complain were those three things separate resources; alas, they’re not.
Every time someone raises this issue, they are shot down by people like you, with the same nonsensical argument—just because the maintainers write cool demos in a fringe datavis DSL, that doesn’t automatically mean it’s helpful for the 99% use case of rendering charts in normal apps.
"Observable is obnoxious if you want to add a D3 pie chart to your Vue application and have to untangle calls to D3’s API from reactive cell values, which look like ordinary JavaScript, but are not, and will cause compilation and runtime errors when copied."
Yep - as I wrote: "If you want to just blindly copy and paste d3 code, you may have issues with the docs being hosted on observable."
If instead you learn the core api (selections, bindings, and update patterns), any chart is really just a matter of using the correct layout/generator.
> it’s odd to attack observable since everything they put out is fully open-source
Really? They've finally open-sourced the notebook editor? I can't find it on their GitHub. The long-proprietary notebook editor is a big part of people's objections to Observable.
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.
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.
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.
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.
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.
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.
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.
> 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)
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.
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.
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 ...
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)
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.
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.
Thanks for sharing, evidence looks very interesting. Reading the docs, do I understand it right that I need to publish parquet files so that WASM DuckDB could query them. I’m a bit concerned users wholesale downloading all the data.
What a complete exhaustive set of examples! Very useful. Both SVG and Canvas renderers differ very little and both seem to be super performant. The declarative API is just so simple... harkens back to the age of batteries-included web frameworks like Ext.
We evaluated pretty much every option and it's the best non-react option. Recharts honestly seems a little nicer if you're using React, but our frontend is in Vue.
Even if one is using react, I think there's value in choosing libraries that are not deeply tied to react such that that logic can be reused when (not if) we need to start migrating away from it.
The problem is non-react chart libraries can be a bit cumbersome to use in React. For example, D3 controls the DOM itself through various transformations. React is not aware of these updates and combining react's state based DOM manipulation with random updates from a charting library gets messy.
A very large library of premade charts for web. Probably the largest I've seen. Less customizable than chart.js, and D3 is more of a rendering library than a charting library.
I'm surprised by your claim of it being less customizable than chart.js, it has been very flexible from my experience.
It could rival d3 with a lot of customization and a worse DX from what I've seen: It's essentially a good amount of defaults, but you can override and replace essentially anything.
22.7MB to download the latest release from Github (87.3MB unzipped). That's an insane amount of JS to download and compile (people often complain about React being ~50kb).
The default recommended way to use it is `import * as echarts from 'echarts'` which means you are getting the WHOLE thing.
Does anyone with experience know how big is it when you pick and choose modules?
Not that big if you pick just what you need (but still quite a lot of kb to be fair). Take a quick look at their online builder and test it for yourself https://echarts.apache.org/en/builder.html
I don't think I ever see Wechat and Weibo in the "Follow Us" box. Was this donated to Apache by a Chinese company? I feel like we will see a lot more of this in the coming years.
Agreed - geopolitics aside, it's been awesome to see how much Chinese companies have embraced open source in a number of different domains. I think the whole ecosystem is going to greatly benefit from the contributions of Chinese open source projects.
I would love it if was possible to download the rendered chart, ideally headless. In peak traffic I would prefer to switch to a pre-rendered version, have the pre-rendered version available encase of an error (i.e. data retrieval), or for users not using JS.
After the most minimal Google-foo, I see echarts-python [1] which has not been updated in 9 years. pyecharts [2] is looking pretty well maintained though.
Years ago I tried my hand at writing a simple bar/line plotting filter for Pandoc that embeds itself into documents via an SVG in a URI [3]. If HN is permitting, you can past links like so [4]. I think writing a stand-alone tool to display the data you are interested in is a good idea for anybody.
You can easily download a rendered chart by using the chart's getDataURL() function. Then just create a new element in your document and set that element's href to the return from getDataURL() and bob's your uncle.
It’s probably more performant. Chart.js isn’t designed for a ton of data and we recommend sampling before visualization . We have a builtin plugin that does a form of min/max sampling to retain peaks but cut down on the amount of data points drawn
I like ECharts a lot and generally, it was incredibly easy to use and customize. I tried a lot of alternatives that weren’t nearly as full featured. It’s really got most anything you’d want included in outta the box.
With that said, I had trouble getting it to stream updates, and was having big performance issues with the dataset I was throwing at it (full telemetry from a racing sim roughly every 12ms). I did not make any attempt to refine the data before delivering it so YMMV. I eventually switched to Plotly and D3 to get better performance, but definitely missed the ease of use.
Sorry if this is a silly question but how does a project become "Apache"? Like is there a core team starting these projects or is there an application process for a project to be under the Apache banner?
We [1] use ECharts to visualize all of our data and it's pretty great to use.
It's also very pluggable, so one can only import the components one needs for each chart.
Meaning if you only use the `bar` series type, you can just only import the `bar` component. Same thing not only for other chart types but also stuff like mark areas or zoom controls.
There's also a bigger update in the work which brings e.g. violin plots.
We moved from plotly to eCharts at OpenObserve, having faced too many small things that we had to fight with plotly. Haven't looked back since the migration.
As an aside, wikimedia is switching all their chart support from vega to echarts.
I'm not an expert on either, but my impression is that vega tries to do literally everything using a custom json syntax which can get confusing and unwieldly. Echarts is a bit more straightforward at least for the simple case.
Vega has a questionable security track record which is concerning if you let untrusted users define graphs.
We use Vega pretty heavily, its a broader ecosystem. Where it really shines is in combination with Altair and Vegafusion to do number-crunching on the backend and return a chart spec that can just be rendered on the front-end.
That makes it particularly useful when building interactive visualizations with a lot of data.
Just recently (like 2 months ago) I had the task to evaluate proper OSS replacements for the main charting of a client. So far, they've used a paid solution - but there have been a couple of reasons why the wanted to migrate.
Needless to write that eCharts was the clear winner. Not only is it greatly customizable, fully feature complete - it also had similar performance data as their paid solution. And performance matters as their largest chart has around 300k data (we discussed and could maybe be satisfied with 80-100k as well - but for most OSS charting libs even that would be pretty much impossible to render quickly).
For everyone who is looking for something super easy and quick it might not be the best solution (personally I like Chart.js in this area the most), but if you want a charting solution that out of the box is fast and comes with everything you might ever need then eCharts is for you.
Installing from random npm repos is so sketchy with supply chain attacks.
Is there such a thing as a security audited open source distro kinda like some of the ultra old kernel versions RHEL carried for so long?
There is a market for “here are trailing versions of popular npm, cargo, etc libraries that go through some kind of audit and approval process”.
I’m not sure of the logistics of how it would work, but developers ripping random high churn libraries off the internet is completely crazy from a security perspective. But somehow it’s the norm outside of a small subset of massive tech companies.
Most big orgs just put in some kind of pass through proxy looking for known signatures and call it a day. I want stripped down functionality, real reviews, and just straight up banned libraries if they can’t find anything that passes.
I’ve had good luck generating charts with gnuplot and serving them as static images—keeps things simple and easy to cache. Haven’t had a need for a full JS charting library yet, but I can see the appeal.
what's the best way to use a JS visualization library like this while using python for data extraction / manipulation in a notebook format (eg. Jupyter notebook, Google Colab, etc.) ?
I've been meaning to practice some data visualization tasks... If anybody knows any cool datasets they'd recommend that aren't your run of the mill kaggle consumer data or whatever. I'm particularly interested in bioinformatics/genetics data but not really sure of where to look (and have almost no background, just personally interested in comp-bio).. If anyone could recommend cool and open esoteric data/possible projects, that would be awesome.
No opinion on this particular package. But on the naming, "Apache" ECharts...
It's long since time that Apache foundation projects stop using the Apache name. Apache is a license, a foundation, a webserver. Apache supported projects have little to do with that - not the same people, not the same product area. Just some help with money and logistics.
And for those that argue the tie to the Apache org:
Anybody have experience using echarts with Vue 2.6? This looks way easier to implement than chart.js, but I’m worried about compatibility with such an old Vue build.
This is great. I was always looking for a well licensed library that is well maintained and ships a coherent featureset. This seems to tick all the boxes.
I've been using apache echarts for a while. It is excellent. As you dig deep, some of the examples and libraries are in Chinese, which can be challenging.
The only real drawback that I've discovered is that it uses canvas to generate the charts. So, when you UI changes to dark mode, you need to reload your charts to update the color scheme ... which in the grand scheme of things is really minor.
The `echarts4r` [1] R package lets you create ECharts charts directly in R and render them in graphical device, Shiny apps, Rmarkdown or Quarto documents.
Over the last 7 years I've built 3 major products that needed charts. Every time I tested most of (at that time) popular solutions. All 3 times eCharts was by far the best option, across all criteria. Incredible library!
Happy eChart user. Added a tiny Reactjs wrapper on the top and ditched all D3 libraries. Never look back. Easy to inline and embed into slatejs based documents. Usable on mobile and responsive enough for my use cases.
Nothing prevents the ECharts project developers themselves to package Echarts and contributing the package to Debian, either by being sponsored by existing Debian Developers, or possibly becoming Debian Maintainers themselves, allowing them to upload a new package at any time without going through anyone else.
True, but it is unlikely they would work on that. Usually upstream developers prefer people to not use distros to get binaries of their code. They already have an npm package and suggest people use it, there isn't much point additional external packaging systems after that. Also, packaging JavaScript/TypeScript stuff for Debian isn't trivial due to the volume of dependency packages that are typically not yet packaged, and other issues.
Wow what a blast from the past. I used this library many years back when I think it was called Baidu E-Charts. Was a great library back then too. I'm amazed how good its gotten now.
longterm google charts user. This has attraction. Good eye candy feel, responsive.
There are some specific things google charts do, like mark out kashmir and other disputed territories differently depending on your origin IP/AS so you don't fall foul of Indian law.
There are some things google charts don't do, like re-center maps off the meridien they think is best. Scaling geo charts for the pacrim island nations is also very hard. No good choices there perhaps.
I've probably used Apache e-charts in some way or another in every project I've been on in the last decade. One of those packages that just works out of the box.
I was particularly impressed with how performant the demo was as it was playing. I was fully expecting my Macbook-fan to start whirring as it usually does with most javascript-heavy pages.
Funny seeing this here with your comment, as I was exploring using ECharts for a project recently to work exactly with HTMX from a Clojure backend. I eventually settled on Chart.js as I found that for my use case, I wanted the charts to more easily fit their dynamically sized container, which isn’t quite as simple with ECharts and Vega. I also didn't need particularly complex plots. Nevertheless, this is a nice project! There remain some open challenges with web-based visualisation libraries more generally around responsive design and accessibility, but we’ve come a long way.
after trying many charting, we settled on Apache Echart as well. its really flexible for lot of use-cases and customizable.
if this doesnt work for you, the only option left is D3.
Btw, we have not looked at many paid chart options like hicharts or other.
It's not in the demo video, but it's in the demo gallery. That's also the thing that's linked as "demo" on the landing page, so I thought you were talking about that.
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.
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".
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 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.
Plotly is full of undocumented features. My guess is because they have an entire consulting business helping devs with this
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.
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.
And upgrading between even minor versions sometimes completely breaks stuff. :(
How is it better than Chart.js? Im curious as the implementations look extremely similar.
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
Hmm I see, will try the apache one, thanks for the input
Did you compare to vega/vega lite? Curious to hear how they compared!
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.
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.
same experience
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...
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
Now that’s incredible
[flagged]
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.
A large number of developers/users of Apache ECharts also seem to be Chinese.
Oooo thank you for mentioning that. Looks quite feature rich !
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.
There's one more thing. Leader of antv is the developer of echarts.
really? how/why?
[dead]
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!".
What about D3js? I know that D3js is low level, but with AI it's pretty easy.
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.
There's Plot, which is as standalone as anything[0]. That said, I still find D3 unparalleled in depth and scope.
[0]: https://github.com/observablehq/plot
I used Plot for an academic paper I wrote recently. It was the only charting library that I found that let me generate the charts I wanted to draw - which in my case was a grouped bar chart with a logarithmic scale. Ie:
https://github.com/josephg/egwalker-paper/blob/master/diagra...
I didn't try echarts though. I might have to give it a go if its good.
I reckon you can get something quite similar with matplotlib without too much trouble, though that strongly depends on how comfortable or familiar you are with it.
It's a shame - and I'm not sure why they did it other than to use D3.js' popularity promote Observable.
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?
> When did Observable get their hands on D3?
Observable and D3 were created by the same person.
Past few years but I don’t have a timeline handy. I am probably ignoring important details but Mike Bostock cofounded observable maybe 4-5 years ago? So for all intents and purposes they have always been the same crew but they made a conscious decision to tightly intertwine d3 docs with observable notebooks.
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).
Look, it’s not “bizarre” to point out that Observable has deeply shaped the modern D3 ecosystem. The issue isn’t that the D3 API has changed, it’s that a huge number of learning resources, examples, and docs have been rebaked into Observable’s reactive notebook style, which, for people not using Observable, adds a ton of indirection and mental overhead.
You might not notice it if you already know D3 inside and out, but for newcomers, it’s a bit of a turnoff. It’s ok if you like it though!
And no, this isn’t about “blindly copying and pasting.” It’s about people wanting to use D3 without having to learn an entirely different execution environment. That’s a reasonable boundary to set, especially when time and focus are finite.
You can use as many italics as you want but I don’t think it’s a wildly bold claim and your counter example is simply silly.
Pre-observable, I used d3 to develop a very complex visualization with real-time updates. It was difficult because d3 has a lot well-thought-out-but-complex concepts, but the docs and examples helped me fully understand how it worked, and the result turned out spectacular.
A few years later, I needed to build a simple novel visualization. A major new version of d3 had come out, and all the examples and documentation got Observable-ified.
Enough time had passed that I could only vaguely recall some of the original concepts, so I set out to re-learn. YMMV but, for me, it was impenetrable. With the limited time I had, I just couldn’t figure out how to untangle d3 from observable. I gave up. Very sad.
Same story here, landed on Apache Echart (it seems, like many others)
> You can use as many italics as you want
Wait. This is actually hilarious.
I'm an experienced dev and looked seriously into D3 some month ago for the first time. I can confirm what you wrote. The notebooks feel like an unnecessary hurdle. It's not a big hurdle, but one that could be avoided so a slightly annoying experience.
"You can use as many italics as you want but I don’t think it’s a wildly bold claim and your counter example is simply silly."
I don't understand the relevance of any of this, but I think I've done a fair job outlining my points above. Let me give my best summary: the execution environment used by a library's (example) documentation is independent from learning the API of the library itself. I agree that newcomers to JavaScript may find plenty of confusion there, and I'm sure a decent chunk of D3's users may be new to web-programming in general, but it's not the job of D3 maintainers to account for that.
I actually think our back-and-forth is a perfect example of why open-source is so painful to work on.
D3 is one of the best documented libraries out there is. There are multiple books, hundreds of hours of youtube videos, and most importantly, dedicated maintainers (Mike Bostock, Philippe Riviere, etc.) who've poured hours into additional sources of documentation and are very responsive on GitHub issues.
The unfortunate outcome here is that users have come to expect this sort of high-quality support and documentation (again with the italics, who does this guy think he is???). Every D3 submodule has standard api documentation, sure, but thats expected of all libraries these days. However, the additional example documentation (again, nobody got paid to make this material) for the most recent releases has been migrated from bl.ocks.org (a now defunct open-source service users didn't pay for it) to Observable Notebooks. Now, Observable is a VC-backed business, yes, but the documentation is still completely free. In this thread, you mention you don't like this, so in at least one online conversation where D3 comes up, you actively advocate against using it out of principle! (Couldn't resist!).
Of course this is just my viewpoint on what has transpired, and I'm likely articulating it in a more-inflammatory-than-reality manner. But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all. Even more so if it helps out the authors of the open-source library.
As a tip for those who have difficulties going from the reactive Observable model to vanilla js -> you can always just take an observable notebook and ask AI to convert it to a set of vanilla files for you.
PS - Sorry for the novel, at an airport!
Appreciate the lengthy response, but I want to clarify a few things since I think my original point keeps getting mischaracterized.
First, the italics. You opened with “This is a very bizarre take”—emphasis on very—which, whether you intended it or not, sets a smug tone. It’s the kind of rhetorical move that shuts down discussion before it starts. I’m not saying this to nitpick style, but to point out how quickly this moved from a discussion about tooling to a dismissal of my viewpoint. It is an easy tell the person writing gives away when they use it like you do.
Now, to the substance: yes, the D3 API is technically independent of Observable. But in practice, Observable is now the primary medium through which new users encounter and learn D3. The official examples, new documentation, and most teaching material are embedded in the Observable environment, which introduces its own model of reactivity, syntax, and execution. That’s not a minor detail, it’s a real obstacle for people who just want to understand and use D3 in plain JavaScript.
Your PyTorch/mkdocs analogy completely misses the mark. Mkdocs is a static site generator. It doesn’t change the code you’re learning—Observable, on the other hand, does. You can’t meaningfully learn D3 from many of these new examples without understanding how Observable cells work. That’s a tight coupling, and one I don’t think should be hand-waved away.
“Just use AI to convert the notebook” is a non-answer. It assumes everyone is okay with outsourcing understanding to a black box just to get a usable snippet. That’s exactly the kind of indirection I’m objecting to in the first place.
Lastly, yes, I’ve set a personal boundary: I don’t want to buy into an ecosystem that made a choice I don’t support. That’s not a call to boycott, it’s just me saying, this direction doesn’t work for me. If that’s enough to dismiss my view as bizarre, then I’m not sure what kind of discussion is even possible here.
Entirely unrelated, but I've not heard anyone describe it as `outsourcing understanding` until now. That's a great phrase.
> you can always just take an observable notebook and ask AI to convert it to a set of vanilla files for you.
D3.js docs used to be fine. Now you need to "ask AI" to untangle them?
> But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all
This is the core point. Yes of course the existing d3js docs are better than nothing. That isn't the complaint. The complaint is the current docs are significantly worse than older d3js docs that weren't notebook-based.
Can you provide an example? I’ve been using d3 on-and-off for almost 10 years, and the core docs have just gone from README’s to static-hosted pages with the same (version-specific) content (eg https://d3js.org/d3-selection/selecting). What is significantly worse here between the two? To my eyes, they’re basically identical: https://github.com/d3/d3-selection/tree/86
My best guess is that you’re referring to bl.ocks.org, which hosted d3 examples as standalone html examples, but this was independent from the d3 docs.
The issue isn’t that the API documentation has disappeared, it’s that the learning experience for newcomers has degraded. The Observable-first direction has made it significantly harder for new users to grok D3 without buying into an entirely new runtime and mental model. Yes, the docs are technically still there, but they’re increasingly fragmented, and many examples now assume you’re using Observable or some variation of its reactive notebook model.
Bl.ocks.org wasn’t officially part of the D3 docs, but it played a critical role: it was the on-ramp. People learned by tweaking examples, not by reading method signatures in isolation. Saying people just want to “copy-paste” kind of misses the point, examples are how many developers build actual understanding. They’re not just blindly pasting code; they’re reverse-engineering patterns, figuring out how the pieces fit together.
We get it — you enjoy the library. But many users don’t appreciate the direction it’s taken. Such a bizarre defense. I guess we are not supposed to look at the examples when trying to grok a new library, especially a library for chart visualizations which is historically not known to be the easiest to work with.
Ah, the good old "you’re not allowed to criticise open source projects, because they’re open source!"
Observable is cool when you want to build data notebooks. Observable is obnoxious if you want to add a D3 pie chart to your Vue application and have to untangle calls to D3’s API from reactive cell values, which look like ordinary JavaScript, but are not, and will cause compilation and runtime errors when copied.
The problem is that D3 resources mix D3 documentation with demos of D3 itself, and demos of Observable, into a single, inseparable combination. Nobody would complain were those three things separate resources; alas, they’re not.
Every time someone raises this issue, they are shot down by people like you, with the same nonsensical argument—just because the maintainers write cool demos in a fringe datavis DSL, that doesn’t automatically mean it’s helpful for the 99% use case of rendering charts in normal apps.
"Observable is obnoxious if you want to add a D3 pie chart to your Vue application and have to untangle calls to D3’s API from reactive cell values, which look like ordinary JavaScript, but are not, and will cause compilation and runtime errors when copied."
Yep - as I wrote: "If you want to just blindly copy and paste d3 code, you may have issues with the docs being hosted on observable."
If instead you learn the core api (selections, bindings, and update patterns), any chart is really just a matter of using the correct layout/generator.
Here's d3 pie: https://d3js.org/d3-shape/pie
No need for going into Observable at all, as the pie generator is completely documented.
But if, as you mentioned, you prefer to copy the code from Observable, the linked pie example is extremely simple to do so: https://observablehq.com/@d3/donut-chart/2
Zero reactive cells, you can literally just copy the code inside the cell statement (e.g. the curly braces).
> it’s odd to attack observable since everything they put out is fully open-source
Really? They've finally open-sourced the notebook editor? I can't find it on their GitHub. The long-proprietary notebook editor is a big part of people's objections to Observable.
> They've finally open-sourced the notebook editor?
They didn't because it's literally their core business.
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.
Not touching D3.js since Observable.
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.
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'm a big fan of VisX for the level of control it gives.
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.
VisX looks nice. We haven't had the need for more complicated visualizations yet but I'm always looking out for options.
I can second this. VisX will be a little more effort but it will let you build anything you could build using d3.
I like Plotly.
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.
They publish plotly.js and react bindings as well.
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).
how is it compared to ag-grid chart?
We did not evaluate libraries that have a paid plan
What about Vega?
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.
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.
https://en.wikipedia.org/wiki/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.
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.
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.
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.
https://en.wikipedia.org/wiki/Ornament_and_Crime
> 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.
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.
Fully agree. He must have been itching to use the term "chart junk" :-)
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).
Props to Hans Rosling I think:
https://www.youtube.com/watch?v=hVimVzgtD6w (2003)
Something's off here. The data appears as "life-expectancy-table.json" but the title refers to Income. Not sure where the mistake is.
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...
>>By the way, well done Norway.
I wonder how well it correlates with the oil price.
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...
https://chartscss.org/
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).
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.
Chart css is like any of the other numerous libraries that can draw a line chart. It is a world apart from echarts.
> 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
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.
The animation examples for chartscss are annoying. it doesn't look nearly as functional
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.
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.
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.
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.
> 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)
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.
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.
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 ...
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)
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
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.
https://apache.github.io/echarts-handbook/en/best-practices/...
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.
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.
1. https://sourcetable.com
Your product looks great. Do you have an open-source or self-hosted version for companies with strict security requirements?
Not presently. We'll do an enterprise push at a later date.
Apache Superset switched many of their interesting charts over to ECharts:
https://preset.io/blog/2021-4-1-why-echarts/
Look at Superset chart implementations and component choice all the time.
Thank you, I thought these looked familiar somehow.
Impressive work! Their main demo there pays some homage to Mike Bostock's d3 transitions showcase from 2011: https://mbostock.github.io/d3/talk/20111116/transitions.html (click to start)
We use ECharts extensively in Evidence (https://github.com/evidence-dev/evidence). Overall has been a delight.
Thanks for sharing, evidence looks very interesting. Reading the docs, do I understand it right that I need to publish parquet files so that WASM DuckDB could query them. I’m a bit concerned users wholesale downloading all the data.
Examples from this fairly custom implementation: https://docs.evidence.dev/components/all-components/
Such an amazing project! Although I don't have any use case as of right now, will definitely keep this one in mind.
Superset[1] BI tool is a good example of how useful ECharts are
[1] https://superset.apache.org/
Just a nit: the part that describes its mobile optimized (and pretty much all other pages describing the features) does not load correctly on mobile.
https://echarts.apache.org/en/feature.html#mobile
What a complete exhaustive set of examples! Very useful. Both SVG and Canvas renderers differ very little and both seem to be super performant. The declarative API is just so simple... harkens back to the age of batteries-included web frameworks like Ext.
Late to the party here but we (Sentry) have been using ECharts since 2018 (https://github.com/getsentry/sentry/pull/9072) and still holding strong!
I really wish the “slowly fade elements in as they scroll onto the screen” would die.
we use eCharts for all the visualizations in https://www.definite.app/.
We evaluated pretty much every option and it's the best non-react option. Recharts honestly seems a little nicer if you're using React, but our frontend is in Vue.
Even if one is using react, I think there's value in choosing libraries that are not deeply tied to react such that that logic can be reused when (not if) we need to start migrating away from it.
The problem is non-react chart libraries can be a bit cumbersome to use in React. For example, D3 controls the DOM itself through various transformations. React is not aware of these updates and combining react's state based DOM manipulation with random updates from a charting library gets messy.
What does this have over Plotly, Chart.js, D3, Bokeh, etc
A very large library of premade charts for web. Probably the largest I've seen. Less customizable than chart.js, and D3 is more of a rendering library than a charting library.
I'm surprised by your claim of it being less customizable than chart.js, it has been very flexible from my experience.
It could rival d3 with a lot of customization and a worse DX from what I've seen: It's essentially a good amount of defaults, but you can override and replace essentially anything.
I'd forgotten all about this library, its certainly come a long way!
Can you name one thing that chart.js does that Apache ECharts cannot do?
I wrote a bit about that here: https://preset.io/blog/2021-4-1-why-echarts/
Thanks! I actually use Superset and echarts does work well on it
22.7MB to download the latest release from Github (87.3MB unzipped). That's an insane amount of JS to download and compile (people often complain about React being ~50kb).
The default recommended way to use it is `import * as echarts from 'echarts'` which means you are getting the WHOLE thing.
Does anyone with experience know how big is it when you pick and choose modules?
In fairness that would be all the charting options baked in. Typically you only install the specific charts you are using.
Not that big if you pick just what you need (but still quite a lot of kb to be fair). Take a quick look at their online builder and test it for yourself https://echarts.apache.org/en/builder.html
The lib is modular
My current build for an analytics dashboard app uses:
...and comes out at 550kb minified but unzippedUmm, minified version from site is 335.50 kB gzipped /1.03 MB.
I don't think I ever see Wechat and Weibo in the "Follow Us" box. Was this donated to Apache by a Chinese company? I feel like we will see a lot more of this in the coming years.
Agreed - geopolitics aside, it's been awesome to see how much Chinese companies have embraced open source in a number of different domains. I think the whole ecosystem is going to greatly benefit from the contributions of Chinese open source projects.
It is a country with public adverts explicitly saying "America/west is the enemy". Supply chain attacks via open source are already happening.
The library originates from a team of developer from a chinese Company (Baidu I think).
I saw that the rendering library for echarts, zrender, is managed by a GitHub org associated with Baidu
https://github.com/ecomfe
It's made by Baidu and Apache is sponsoring them (why I don't know, Baidu must have enough money right?)
The only thing I ever want out of these chart libraries is to be able to theme them. Does anyone know how customizable the theming for ECharts is?
I was curious about this too, and I found https://echarts.apache.org/en/theme-builder.html
It's pretty extensively customisable
Certainly colours, fonts and sizes are all configured at the 'theme' level, plus the charts themselves have a lot of visual variations to choose from
I don't think you would have any problem making it fit with the style of your site
It might be able to: https://echarts.apache.org/en/option.html#color
I would love it if was possible to download the rendered chart, ideally headless. In peak traffic I would prefer to switch to a pre-rendered version, have the pre-rendered version available encase of an error (i.e. data retrieval), or for users not using JS.
After the most minimal Google-foo, I see echarts-python [1] which has not been updated in 9 years. pyecharts [2] is looking pretty well maintained though.
Years ago I tried my hand at writing a simple bar/line plotting filter for Pandoc that embeds itself into documents via an SVG in a URI [3]. If HN is permitting, you can past links like so [4]. I think writing a stand-alone tool to display the data you are interested in is a good idea for anybody.
[1] https://github.com/yufeiminds/echarts-python
[2] https://github.com/pyecharts/pyecharts/blob/master/README.en...
[3] https://gitlab.com/danbarry16/pandoc-highlight-filter/-/blob...
[4] (removed link as it was too long for the comments section)
You can easily download a rendered chart by using the chart's getDataURL() function. Then just create a new element in your document and set that element's href to the return from getDataURL() and bob's your uncle.
I need to check that out, thank you!
Related, I just wrote an article and demo about enabling Apache ECharts in React[1] this week.
[1] https://tania.dev/apache-echarts-react/
How does it compare to https://www.chartjs.org/ ?
It's much heavier but a lot more powerful and flexible.
Thanks! And is it more or less performant on large datasets (100k+ data points).
maintainer of chartjs here.
It’s probably more performant. Chart.js isn’t designed for a ton of data and we recommend sampling before visualization . We have a builtin plugin that does a form of min/max sampling to retain peaks but cut down on the amount of data points drawn
Hey! Thanks for maintaining chartjs :)
maintainer of uPlot here :)
they're about same for line chart rendering when using decimation in both.
Wow, that's cool, thanks for working on it, I've been using Chart.js for many years :)
Performance seemed quite good with Chart.js in my case, for small to medium datasets.
The biggest difference I'm aware of is that ECharts has an add-on for 3D charts (echarts-gl). Chart.js doesn't have any 3D functionality.
(Our project mostly uses Chart.js, so I'm more familiar with it.)
This is super slick. I remember spending hours maybe days trying to make MRTG or rrdtool graphs look like these.
We use Echarts on our Bluesky analytics site
https://bluefacts.app/profile/bsky.app
Really great experience, we optimized the imports to reduce bundle size.
For https://www.appbrain.com we also use it and had to optimize it even more.We render it server side and only return the SVG to the client.
Server side rendering is a very powerful feature only very few chart libraries support.
https://apache.github.io/echarts-handbook/en/how-to/cross-pl...
also they have a very lightweight client library to add back interactive things like popups on hover when using server side rendering
I like ECharts a lot and generally, it was incredibly easy to use and customize. I tried a lot of alternatives that weren’t nearly as full featured. It’s really got most anything you’d want included in outta the box.
With that said, I had trouble getting it to stream updates, and was having big performance issues with the dataset I was throwing at it (full telemetry from a racing sim roughly every 12ms). I did not make any attempt to refine the data before delivering it so YMMV. I eventually switched to Plotly and D3 to get better performance, but definitely missed the ease of use.
Sorry if this is a silly question but how does a project become "Apache"? Like is there a core team starting these projects or is there an application process for a project to be under the Apache banner?
I believe it's the latter.
https://incubator.apache.org/
We have been using Apache ECharts in our products[1] since 2020.
Cannot recommend it enough - absolutely fantastic library, great documentation, zero issues of any impact to us in five years.
My only wish is for the keyboard accessibility ticket[2] to get some love!
[1] https://factorhouse.io
[2] https://github.com/apache/echarts/issues/14706
Funny to see you here. I’m from operata.io (also a Melbourne based startup) and would see your website (operatr.io) when I would mis-spell mine!
We [1] use ECharts to visualize all of our data and it's pretty great to use.
It's also very pluggable, so one can only import the components one needs for each chart. Meaning if you only use the `bar` series type, you can just only import the `bar` component. Same thing not only for other chart types but also stuff like mark areas or zoom controls.
There's also a bigger update in the work which brings e.g. violin plots.
[1] - https://donation.watch/
We moved from plotly to eCharts at OpenObserve, having faced too many small things that we had to fight with plotly. Haven't looked back since the migration.
Do anyone have experience with this in comparison to vega?
As an aside, wikimedia is switching all their chart support from vega to echarts.
I'm not an expert on either, but my impression is that vega tries to do literally everything using a custom json syntax which can get confusing and unwieldly. Echarts is a bit more straightforward at least for the simple case.
Vega has a questionable security track record which is concerning if you let untrusted users define graphs.
We use Vega pretty heavily, its a broader ecosystem. Where it really shines is in combination with Altair and Vegafusion to do number-crunching on the backend and return a chart spec that can just be rendered on the front-end.
That makes it particularly useful when building interactive visualizations with a lot of data.
Just recently (like 2 months ago) I had the task to evaluate proper OSS replacements for the main charting of a client. So far, they've used a paid solution - but there have been a couple of reasons why the wanted to migrate.
Needless to write that eCharts was the clear winner. Not only is it greatly customizable, fully feature complete - it also had similar performance data as their paid solution. And performance matters as their largest chart has around 300k data (we discussed and could maybe be satisfied with 80-100k as well - but for most OSS charting libs even that would be pretty much impossible to render quickly).
For everyone who is looking for something super easy and quick it might not be the best solution (personally I like Chart.js in this area the most), but if you want a charting solution that out of the box is fast and comes with everything you might ever need then eCharts is for you.
Installing from random npm repos is so sketchy with supply chain attacks.
Is there such a thing as a security audited open source distro kinda like some of the ultra old kernel versions RHEL carried for so long?
There is a market for “here are trailing versions of popular npm, cargo, etc libraries that go through some kind of audit and approval process”.
I’m not sure of the logistics of how it would work, but developers ripping random high churn libraries off the internet is completely crazy from a security perspective. But somehow it’s the norm outside of a small subset of massive tech companies.
Most big orgs just put in some kind of pass through proxy looking for known signatures and call it a day. I want stripped down functionality, real reviews, and just straight up banned libraries if they can’t find anything that passes.
ECharts powers all charts in tablab.app. Might be using 20 different chart types or so
Very happy with it.
Theming works well (saw a question or two about that)
We are actually using Apache ECharts to visualize system performance data in real-time using eBPF.
We had to do a bunch of stuff on top of it to get it working but all in all pretty nice.
You can check it out here in our sandbox:
https://yeet.cx/play
Getting a 503 with that link.
The demo page is ridiculously long. I ran out of things to search for. Well done!
https://echarts.apache.org/examples/en/index.html
I’ve had good luck generating charts with gnuplot and serving them as static images—keeps things simple and easy to cache. Haven’t had a need for a full JS charting library yet, but I can see the appeal.
It's developed by Tencent developers. Probably if you would like to get chart of China crimes against humanity you would get an error ;-)
what's the best way to use a JS visualization library like this while using python for data extraction / manipulation in a notebook format (eg. Jupyter notebook, Google Colab, etc.) ?
might want to give https://pyecharts.org/#/ a try. After data manipulation in a notebook, import pyecharts and use their api to create an echart
Oh, good that it can choose between canvas or svg. https://apache.github.io/echarts-handbook/en/best-practices/...
Canvas is the only game in town if you have huge amount of datapoints.
I've been meaning to practice some data visualization tasks... If anybody knows any cool datasets they'd recommend that aren't your run of the mill kaggle consumer data or whatever. I'm particularly interested in bioinformatics/genetics data but not really sure of where to look (and have almost no background, just personally interested in comp-bio).. If anyone could recommend cool and open esoteric data/possible projects, that would be awesome.
Could try these:
https://www.ncbi.nlm.nih.gov/datasets/
https://github.com/OpenGene/awesome-bio-datasets
Thanks!
No opinion on this particular package. But on the naming, "Apache" ECharts...
It's long since time that Apache foundation projects stop using the Apache name. Apache is a license, a foundation, a webserver. Apache supported projects have little to do with that - not the same people, not the same product area. Just some help with money and logistics.
And for those that argue the tie to the Apache org:
They're not CNCF Kubernetes, CNCF Helm, CNCF Jaeger. They're Kubernetes, Helm, Jaeger.
> They're not CNCF Kubernetes, CNCF Helm, CNCF Jaeger.
Maybe they should be?
Anybody have experience using echarts with Vue 2.6? This looks way easier to implement than chart.js, but I’m worried about compatibility with such an old Vue build.
Used it extensively with Vue 2, never had any compatibility issues. Moved on to Vue 3 by now, though.
Btw, if you’re looking to migrate to Vue 3, hit me up on github. Handle is the same as it is here :)
This is great. I was always looking for a well licensed library that is well maintained and ships a coherent featureset. This seems to tick all the boxes.
I wish it handled time zones properly, but everything else just works. The number of charts it supports is crazy. The second best was Apexcharts.
https://echarts.apache.org/examples/en/index.html
I've been using apache echarts for a while. It is excellent. As you dig deep, some of the examples and libraries are in Chinese, which can be challenging.
The only real drawback that I've discovered is that it uses canvas to generate the charts. So, when you UI changes to dark mode, you need to reload your charts to update the color scheme ... which in the grand scheme of things is really minor.
The `echarts4r` [1] R package lets you create ECharts charts directly in R and render them in graphical device, Shiny apps, Rmarkdown or Quarto documents.
[1] https://echarts4r.john-coene.com/
The AWS Quicksight BI tool uses it underneath.
Over the last 7 years I've built 3 major products that needed charts. Every time I tested most of (at that time) popular solutions. All 3 times eCharts was by far the best option, across all criteria. Incredible library!
Used this for some knowledge graph visualization work. Really clean UI and some nice features out of box for interactivity
Reminds me of https://d3js.org/
Pleasing visual which had my browser's FPS went low, especially at the liquid fill extension part.
Happy eChart user. Added a tiny Reactjs wrapper on the top and ditched all D3 libraries. Never look back. Easy to inline and embed into slatejs based documents. Usable on mobile and responsive enough for my use cases.
No Debian package. Requested since 2022: <https://bugs.debian.org/1014408>
Unfortunately Debian RFPs generally don't work, unless an existing Debian contributor sees it and also has a need for the project.
Nothing prevents the ECharts project developers themselves to package Echarts and contributing the package to Debian, either by being sponsored by existing Debian Developers, or possibly becoming Debian Maintainers themselves, allowing them to upload a new package at any time without going through anyone else.
True, but it is unlikely they would work on that. Usually upstream developers prefer people to not use distros to get binaries of their code. They already have an npm package and suggest people use it, there isn't much point additional external packaging systems after that. Also, packaging JavaScript/TypeScript stuff for Debian isn't trivial due to the volume of dependency packages that are typically not yet packaged, and other issues.
https://wiki.debian.org/Javascript
Wow what a blast from the past. I used this library many years back when I think it was called Baidu E-Charts. Was a great library back then too. I'm amazed how good its gotten now.
There is a super interesting port of ECharts to Rust: https://github.com/yuankunzhang/charming
The fact that it seamlessly switches between <CANVAS> and <SVG> is marvelous!
longterm google charts user. This has attraction. Good eye candy feel, responsive.
There are some specific things google charts do, like mark out kashmir and other disputed territories differently depending on your origin IP/AS so you don't fall foul of Indian law.
There are some things google charts don't do, like re-center maps off the meridien they think is best. Scaling geo charts for the pacrim island nations is also very hard. No good choices there perhaps.
Is there a migration guide?
Never seen so much positivity related to a tool since SQLite
I've probably used Apache e-charts in some way or another in every project I've been on in the last decade. One of those packages that just works out of the box.
I was particularly impressed with how performant the demo was as it was playing. I was fully expecting my Macbook-fan to start whirring as it usually does with most javascript-heavy pages.
How did I not know about Apache ECharts?!? Thank you HN. This is awesome.
ECharts was handy for getting a quick chart going in a typing practice app I wrote. It was easy to get a chart showing WPM over time on a word list.
The "Examples" page doesn't work for me. I don't get further than "Line Charts". (Firefox)
Does anyone know of a way to print echarts to a PDF, without having a headless Chromium instance involved? Been fighting this at work.
https://www.blog.pythonlibrary.org/2018/04/12/adding-svg-fil... ?
Echarts can correctly animate data thats streaming via a moving window from right to left. Some other libs have issues in this case.
Are ECharts safe for untrusted user input?
The demo is seriously impressive! I haven’t heard of this library before, will definitely consider using it
Looks like it could work nicely with HTMX.
I'm using ECharts with HTMX + AlpineJS, with ECharts wrapped in an Alpine component
I had to disable hx-history to get around a problem of the charts getting double instantiated
it feels a bit of a lame workaround but I never managed to get to the bottom of it
apart from that, totally happy
Funny seeing this here with your comment, as I was exploring using ECharts for a project recently to work exactly with HTMX from a Clojure backend. I eventually settled on Chart.js as I found that for my use case, I wanted the charts to more easily fit their dynamically sized container, which isn’t quite as simple with ECharts and Vega. I also didn't need particularly complex plots. Nevertheless, this is a nice project! There remain some open challenges with web-based visualisation libraries more generally around responsive design and accessibility, but we’ve come a long way.
Did you look at charts.css ?
https://chartscss.org/
This looks great, thanks! I didn't come across this this in my search but I'll definitely try it out.
> more easily fit their dynamically sized container
I've done this for more simpler elements. Copilot helped me come up with a little bit of custom JS in those cases.
Not sure about HTMX specifically, but I've used it with Rails/Hotwire/Stimulus (similar conceptually) and it works great.
after trying many charting, we settled on Apache Echart as well. its really flexible for lot of use-cases and customizable. if this doesnt work for you, the only option left is D3. Btw, we have not looked at many paid chart options like hicharts or other.
I love echarts, I've used it at almost every company I've worked at to this day since I found it.
how long ago did you find it? Maybe you can share the dev progress if it was a few years back.
Nivo seems really nice. I recall that fey.com used it for their charts.
I'd really like to know how they did all the transition effects. They were really cool.
I never heard of them, hmm. Apache doing great work here.
Times sure do change - nice acquisition- hope it stays open
How is the Apache project still alive? Who funds them?
https://www.apache.org/foundation/sponsors
What a beautiful presentation!
wow!!
Though it did not seem to have trading related charts like candlesticks and others
This is so cool!
what happened to sankey? no sankey graph??
echarts definitely supports sankey: https://echarts.apache.org/examples/en/index.html#chart-type...
they are missing the mark by not featuring it in their demo. The us national budget comes to mind as a feature clip in the demo for sankey.
I don’t get what you mean, it is featured in the demo. On the landing page, click demo and navigate to sankey in the menu.
sorry, I didn't see it in their featured demo video, unless it was shown supper quick.
It's not in the demo video, but it's in the demo gallery. That's also the thing that's linked as "demo" on the landing page, so I thought you were talking about that.
[dead]
[flagged]
[flagged]
Is it Vibe Coding friendly?
Echarts has good documentation and examples so I think it should be vibe coding friendly when you reference the docs (eg with cursor)
I've found ChatGPT reasonably good at giving me working ECharts configs...