The main issues with other libraries is that they're either:
(a) ugly (b) difficult to use (i.e. having to do things imperatively) (c) not flexible enough
Apache ECharts solve these 3 problems. It's pretty by default, it allows us to mount/calculate the declarative spec for the graphs in the back-end and then only send the desired spec to the front-end so it can render, and it's also extremely flexible to the point we can support everything that traditional BI tools can do.
We've never had to extend the lib to do anything new, everything we need is already there.
Glad to see this great piece of work on top of HN.
* Echarts is about the only dependency in our project that I can upgrade - and be sure it never breaks anything. It is so well-thought in that regard. Upgrading for 3.x to 5.x? Sure! "npm update" and everything just keeps working smoothly. That is so refreshing to see these days. Unbelievable.
* It's both SSR-friendly and SPA-friendly. Being mostly vanilla-js, works seamlessly with both react/vue/apline AND with old-school rails/asp.net/php/whatever. Our app is pretty classic SSR (https://www.jitbit.com/) and I can construct my chart's JSON object on a server using some linq-queries and provide that to echarts.
* ...OR I can give it a reactive object from vue-based SPA. Dun matter, it just works.
* whenever we have to add some workarounds (like, showing hovering labels on a pie chart with a bold percentages or something) - I never have to dig into their sources. Almost anything has already been figured out. Easily googlable and "LLM-able".
for millions of points maybe Canvas rendering is more performant
but for simple charts SVG provides an easier way to get responsive sizing just via CSS without involving JS to re-render
That said, I absolutely love the idea that a blob of JSON living in my database contains everything I need for my visualization. The reality is that not enough other people are willing to put in the effort to learn that syntax, making it somewhat of a selfish tech choice.
It's fun to Go-embed JavaScript functions and SQL queries, for this weird blend of data, SQL, Go and Javascript. Here's a Golang example that pulls data from a DuckDB and creates a baked-in candlestick chart file with JavaScript tooltips. [2]
[1] https://github.com/go-echarts/go-echarts
[2] https://github.com/NimbleMarkets/dbn-duckduck-goose/blob/mai...
It seems good, but their docs websites are absolute trash (though they've seemingly gotten somewhat better recently - they were previously completely unusable).
e.g https://g6.antv.antgroup.com/
Overall, I think you cant go wrong with Apache.
If you scroll down, the entire comment section reads a lot like a campaign to fix their search results & AI suggestibility.
Way too many comments read like generic seller-inserted reviews, eg "Great Product!", "Tried X, Y, Z but this solved my problem!".
Not sure why this is so contentious. You can search online how many others this impacted as well. All of the modern examples for d3 were rebaked into the observable notebook pattern and it seriously obfuscated how to use d3 itself.
If you’re a data viz team and do this all the time, and everyone knows or is willing to learn D3, then sure. Otherwise, if you just need to add a graph to your website, you may find it slows you down and makes code less maintainable.
I personally find it confusing and as others mentioned I can forget how it works over time, though I admire it. I don’t think I could jump in and edit D3 code today without careful study, any more than I could jump in and edit Perl code. Echarts/Highcharts etc. are much more intuitive.
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.
In the animated version, a human observer here is allowed (forced) to occupy mental states of a real-time observer. They have the experience of "X has jumped ahead - I wonder if it'll last - oh, wow, Y is really surging".
The visceral experience matters, and is impossible to recreate post-hoc if all of the info is presented up front.
(edit: "more information" in so far is it informs more - leaves more impressions on the observer)
2. The Chartjunk wiki cites Adolf Loos's idea "ornamentation is a crime". But I think we're done with modern minimalism and in the process of rediscovering the joy in ornamentation. This is an aesthetic choice and you may disagree.
No it removes information; to be able to focus on one period at a time as it evolves.
Seeing a "living graph" of how something evolves is different than seeing the graph fully drawn statically, that cannot be considered chart junk IMO.
if i had a dashboard i needed to use at work set up like that i'd have a bloody conniption after a week. but this isn't a work dashboard -- it's a functionality demo and i'm more likely to remember echarts now as a result (purpose of examples achieved).
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.
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
(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!
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.
That makes it particularly useful when building interactive visualizations with a lot of data.
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 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
I've done this for more simpler elements. Copilot helped me come up with a little bit of custom JS in those cases.
Though it did not seem to have trading related charts like candlesticks and others