Remix clone Hacker News

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.

▲

noduerme 10 days ago | parent | next [-]

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.

▲

jitbit 8 days ago | parent | prev | next [-]

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".

▲

naught0 10 days ago | parent | prev | next [-]

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 10 days ago | parent | prev | next [-]

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 10 days ago | parent | next [-]

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

▲

incoming1211 10 days ago | parent | prev [-]

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 10 days ago | parent [-]

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 9 days ago \| parent [-]
		And upgrading between even minor versions sometimes completely breaks stuff. :(

▲

zwnow 10 days ago | parent | prev | next [-]

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

▲

anentropic 10 days ago | parent [-]

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 10 days ago \| parent [-]
		Hmm I see, will try the apache one, thanks for the input

▲

stuartaxelowen 10 days ago | parent | prev | next [-]

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

▲

spaceribs 10 days ago | parent [-]

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 10 days ago \| parent [-]
		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 10 days ago | parent | prev [-]

same experience