Live data from Hacker News

Apache ECharts

echarts.apache.org

181–190 of 263 posts

Re: Apache ECharts

#182

Earlier quoted context omitted.

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…

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.

Re: Apache ECharts

#184
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.

Re: Apache ECharts

#185
post #135

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?

Umm, minified version from site is 335.50 kB gzipped /1.03 MB.

Re: Apache ECharts

#186
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.

Re: Apache ECharts

#187

Earlier quoted context omitted.

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…

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.

Re: Apache ECharts

#188

Earlier quoted context omitted.

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

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

Re: Apache ECharts

#189
post #158

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 looki…

https://apache.github.io/echarts-handbook/en/best-practices/...
Post reply on HN