Apache ECharts
181–190 of 263 posts
Re: Apache ECharts
#182Earlier 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…
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
#183Re: Apache ECharts
#184Is 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
#18522.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?
Re: Apache ECharts
#186Needless 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
#187Earlier 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…
Re: Apache ECharts
#188Earlier 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.
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
#189Noticed 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…
Re: Apache ECharts
#190Is it Vibe Coding friendly?