[lucasfcosta]

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.

[jitbit]

That, plus:

* Echarts is about the only dependency in our project that I can upgrade - and be sure it never breaks anything. It is so well-thought in that regard. Upgrading for 3.x to 5.x? Sure! "npm update" and everything just keeps working smoothly. That is so refreshing to see these days. Unbelievable.

* It's both SSR-friendly and SPA-friendly. Being mostly vanilla-js, works seamlessly with both react/vue/apline AND with old-school rails/asp.net/php/whatever. Our app is pretty classic SSR (https://www.jitbit.com/) and I can construct my chart's JSON object on a server using some linq-queries and provide that to echarts.

* ...OR I can give it a reactive object from vue-based SPA. Dun matter, it just works.

* whenever we have to add some workarounds (like, showing hovering labels on a pie chart with a bold percentages or something) - I never have to dig into their sources. Almost anything has already been figured out. Easily googlable and "LLM-able".

[noduerme]

I must've looked at this years ago, but for whatever reason, hitched my wagon to Chart.js and haven't really needed anything it couldn't do. And that's for weird one-off custom stuff. For business analytics I just self-host a Metabase server. I wish there were more visualization options with Metabase, but it's such a cinch to set up models and queries. But I don't often get a visualization request that justifies the time to create a custom chart.

[naught0]

I recently had the need to create a gradient line chart with each step on the y-axis representing a color which should blend with its neighbors, and echarts was the only option that made sense to me after trying a few. The lack of obvious react integration initially put me off, but like any js lib it was pretty easy to use anyway. Echarts surprised me - it's great.

[zurfer]

I can't agree with that. eCharts is good, but https://plotly.com/javascript/ is also super nice and I am actively following https://observablehq.com/plot/ which seems on a path to true greatness.

[ramonverse]

Plotly is full of undocumented features. My guess is because they have an entire consulting business helping devs with this

[incoming1211]

plotly... please... I hope I never have to touch that again, the documentation is so bad. It's not on the same level as eCharts.

[disgruntledphd2]

Yeah, agreed.

I particularly "like" the way they have multiple APIs and inconsistent examples across them. Would it kill you to have the same examples in each?

That being said, i generally like the library but the docs are bad.

[justinclift]

And upgrading between even minor versions sometimes completely breaks stuff. :(

[zwnow]

How is it better than Chart.js? Im curious as the implementations look extremely similar.

[anentropic]

One consideration I looked at when choosing between them was I believe chart.js is Canvas-only, whereas ECharts can output SVG

for millions of points maybe Canvas rendering is more performant

but for simple charts SVG provides an easier way to get responsive sizing just via CSS without involving JS to re-render

[zwnow]

Hmm I see, will try the apache one, thanks for the input

[stuartaxelowen]

Did you compare to vega/vega lite? Curious to hear how they compared!

[spaceribs]

I've used both, and while I think Vega has it's uses, it's not nearly as web developer friendly. Frontend engineers want a clear delineation between logic, composition and styling. By combining everything into a JSON document, you sacrifice that developer experience while introducing a lot of bespoke approaches.

That said, I absolutely love the idea that a blob of JSON living in my database contains everything I need for my visualization. The reality is that not enough other people are willing to put in the effort to learn that syntax, making it somewhat of a selfish tech choice.

[RobinL]

As a big user of vega lite I think that's fair. I think it really shines when used by data vis experts, where charts need to be precise, such as in research and analysis contexts. For something like a simple a metrics dashboard I think I'd agree that it may be difficult for devs.

[adeptima]

same experience