Apache ECharts
echarts.apache.org
echarts.apache.org
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 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.
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
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.
* 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".
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...
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.
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.
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).
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.
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 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!
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.
D3.js docs used to be fine. Now you need to "ask AI" to untangle them?
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.
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.
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.
Wait. This is actually hilarious.
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.
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).
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 didn't because it's literally their core business.
Last time I looked at D3 a half decade or so ago I thought it was an open source lib?
Observable and D3 were created by the same person.
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.
It seems good, but their docs websites are absolute trash (though they've seemingly gotten somewhat better recently - they were previously completely unusable).
e.g https://g6.antv.antgroup.com/
Overall, I think you cant go wrong with Apache.
If you scroll down, the entire comment section reads a lot like a campaign to fix their search results & AI suggestibility.
Way too many comments read like generic seller-inserted reviews, eg "Great Product!", "Tried X, Y, Z but this solved my problem!".
I guess it’s specifically a react library, but it’s such a sweet spot of control and built-in convenience. Having all the annoying stuff like curves/axes/scales/shapes handed to you in a pretty un-opinionated way is really nice.
I was at a startup for a few years and I built all of our client’s dashboards in visx. I loved it from the first minute to the last, and have almost no complaints. And there are few few libraries I can say that about!
https://echarts.apache.org/examples/en/editor.html?c=line-ra...
Toggle the switches to trigger the race. By the way, well done Norway.
On YouTube you can see how well this works. There are channels with a huge follower base just existing because of this animation.
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.
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.
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).
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.
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)
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.
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.
I wonder how well it correlates with the oil price.
Beautiful charts, shame it looks defunct now.
Did you even look at echarts demos, or amcharts demos for that matter -- it's basically the same thing, but paid for: https://www.amcharts.com/demos ?
I don't have anything against charts.css, but it's like comparing a children's plastic toy to a real space shuttle. I spend most of my work hours developing a heavy business analytics application (not unlike Apache Superset), and it would simply be impossible to implement it with something like chart.css
I'm using ECharts (and happy with it) but there are some places where I want like a sparkline in every row of a data table, which is a lot of ECharts instances to instantiate, and this lib looks like it'd be great for that.
If there are a huge number of datapoints, this library will paint itself in the corner.
Announcement: “ECharts, a JS charts package” My assumption: It’ll be unmaintained within a year.
Announcement: “Apache ECharts, a JS charts package” My assumption: It’ll be maintained next year.
5 months using Apache Echarts and watch GitHub repository https://github.com/apache/echarts for all activities. The developer team enthusiasm and unity is impressive. It is flexible, powerful, constantly improved and plenty of examples.
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)
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.
Here are some points others haven't mentioned:
(a) Uses canvas by default. Faster than any other library I've used.
(b) Extremely flexible. Want to write your own widget on top of the graphs (eg., a customized tooltip). Possible!
(c) Provides a lot of metadata. Want to get the position of a point in the rendered chart, to use in your code? Entirely possible!
(d) Works really well when importing into legacy web apps. They even provide an option to get a customized build on their site.
(e) Very good at handling streamed data. The animation is very smooth between data changes.
I've been using it for almost 7 years now for various production and personal projects, and it's still my go-to library. Their docs have come a long way since then.
They do have long standing bugs that get annoying, e.g, dealing with 0 when using log scales, provided there are workarounds for it. I haven't noticed any blocking bugs for most common usecases.
Why is it so rarely mentioned in chart libraries comparisons? Its not even listed on the Wikipedia page for JavaScript chart libraries. I discovered it by chance through Apache Superset.
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)
[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
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.
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.
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?
My current build for an analytics dashboard app uses:
echarts.use([
// chart types:
BarChart,
LineChart,
GaugeChart,
PieChart,
// chart features:
TitleComponent,
LegendComponent,
TooltipComponent, // ~30kb
GridComponent, // ~100kb, controls layout (not visible grid lines)
LabelLayout,
DatasetComponent,
// renderer:
SVGRenderer,
]);
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’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
they're about same for line chart rendering when using decimation in both.
Performance seemed quite good with Chart.js in my case, for small to medium datasets.
(Our project mostly uses Chart.js, so I'm more familiar with it.)
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.
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)
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.
also they have a very lightweight client library to add back interactive things like popups on hover when using server side rendering
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/
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!
That makes it particularly useful when building interactive visualizations with a lot of data.
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.
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.
Very happy with it.
Theming works well (saw a question or two about that)
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.
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:
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.
Maybe they should be?
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.
Canvas is the only game in town if you have huge amount of datapoints.
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?
I've done this for more simpler elements. Copilot helped me come up with a little bit of custom JS in those cases.
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
Though it did not seem to have trading related charts like candlesticks and others