Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apache ECharts

echarts.apache.org

Post reply on HN
Print view View original

241–250 of 263 posts

Re: Apache ECharts

#241

Post by infecto »

the_real_cher wrote: post #225
infecto wrote: post #70

Earlier quoted context omitted.

I refuse to use it out of principle that they have intertwined it with observable. All the modern docs for d3 assume you are using observable. So unless you are relying entirely on AI it’s now even harder to grok the documentation. 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…

When did Observable get their hands on D3? Last time I looked at D3 a half decade or so ago I thought it was an open source lib?

Past few years but I don’t have a timeline handy. I am probably ignoring important details but Mike Bostock cofounded observable maybe 4-5 years ago? So for all intents and purposes they have always been the same crew but they made a conscious decision to tightly intertwine d3 docs with observable notebooks.

Re: Apache ECharts

#242

Post by jwilber »

9dev wrote: post #104
jwilber wrote: post #76

Earlier quoted context omitted.

This is a very bizarre take. If you want to just blindly copy and paste d3 code, you may have issues with the docs being hosted on observable. But absolutely zero part of the d3 api (or core design patterns of use) have anything to do with observable. It’s like saying, “I refuse to use PyTorch because their docs are built with mkdocs.” Moreover, even if the coupling were limiting (which, again, it is not), it’s odd t…

Ah, the good old "you’re not allowed to criticise open source projects, because they’re open source!" Observable is cool when you want to build data notebooks. Observable is obnoxious if you want to add a D3 pie chart to your Vue application and have to untangle calls to D3’s API from reactive cell values, which look like ordinary JavaScript, but are not, and will cause compilation and runtime errors when copied. The…

"Observable is obnoxious if you want to add a D3 pie chart to your Vue application and have to untangle calls to D3’s API from reactive cell values, which look like ordinary JavaScript, but are not, and will cause compilation and runtime errors when copied."

Yep - as I wrote: "If you want to just blindly copy and paste d3 code, you may have issues with the docs being hosted on observable."

If instead you learn the core api (selections, bindings, and update patterns), any chart is really just a matter of using the correct layout/generator.

Here's d3 pie: https://d3js.org/d3-shape/pie

No need for going into Observable at all, as the pie generator is completely documented.

But if, as you mentioned, you prefer to copy the code from Observable, the linked pie example is extremely simple to do so: https://observablehq.com/@d3/donut-chart/2

Zero reactive cells, you can literally just copy the code inside the cell statement (e.g. the curly braces).

Re: Apache ECharts

#243

Post by WilTheFarmer »

captainmuon wrote: post #221
miiiiiike wrote: post #81

I’d keep it. 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.

Interesting, I have the opposite association. When I see Apache something, I assume development has ceased and the project is legacy or maintenance only. There is a saying, "Apache is where projects go to die".

I have not heard that saying before... as of 10 April 2025 W3Techs.com rankings Nginx - 33.8% Apache - 26.4% Cloudflare Server - 23.4% LiteSpeed - 14.7% Node.js - 4.3% Microsoft-IIS - 4.0% Envoy - 1.3% Google Servers - 0.8% Caddy - 0.3% IdeaWebServer - 0.1% Percentages of websites using various web servers Note: a website may use more than one web server

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.

Re: Apache ECharts

#244

Post by bjarneh »

helloplanets wrote: post #188
bjarneh wrote: post #177

Earlier quoted context omitted.

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

Fully agree. He must have been itching to use the term "chart junk" :-)

Re: Apache ECharts

#245

Post by pabs3 »

teddyh wrote: post #230

No Debian package. Requested since 2022: https://bugs.debian.org/1014408 >

Unfortunately Debian RFPs generally don't work, unless an existing Debian contributor sees it and also has a need for the project.

Re: Apache ECharts

#247

Post by justinclift »

disgruntledphd2 wrote: post #229
incoming1211 wrote: post #210

Earlier quoted context omitted.

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.

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.

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

Re: Apache ECharts

#248

Post by KomoD »

WilTheFarmer wrote: post #243
captainmuon wrote: post #221

Earlier quoted context omitted.

Interesting, I have the opposite association. When I see Apache something, I assume development has ceased and the project is legacy or maintenance only. There is a saying, "Apache is where projects go to die".

I have not heard that saying before... as of 10 April 2025 W3Techs.com rankings Nginx - 33.8% Apache - 26.4% Cloudflare Server - 23.4% LiteSpeed - 14.7% Node.js - 4.3% Microsoft-IIS - 4.0% Envoy - 1.3% Google Servers - 0.8% Caddy - 0.3% IdeaWebServer - 0.1% Percentages of websites using various web servers Note: a website may use more than one web server 5 months using Apache Echarts and watch GitHub repository https…

> as of 10 April 2025 W3Techs.com rankings Nginx - 33.8% Apache - 26.4% Cloudflare Server - 23.4% LiteSpeed - 14.7% Node.js - 4.3% Microsoft-IIS - 4.0% Envoy - 1.3% Google Servers - 0.8% Caddy - 0.3% IdeaWebServer - 0.1% Percentages of websites using various web servers Note: a website may use more than one web server

How is any of that relevant to parent? People using something doesn't mean it's maintained. (I'm not saying it's not maintained, I just don't see how those numbers are relevant)

Re: Apache ECharts

#249

Post by sunpazed »

d_t_w wrote: post #142

We have been using Apache ECharts in our products[1] since 2020. 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! [1] https://factorhouse.io [2] https://github.com/apache/echarts/issues/14706

Funny to see you here. I’m from operata.io (also a Melbourne based startup) and would see your website (operatr.io) when I would mis-spell mine!

Re: Apache ECharts

#250

Post by teddyh »

pabs3 wrote: post #245
teddyh wrote: post #230

No Debian package. Requested since 2022: https://bugs.debian.org/1014408 >

Unfortunately Debian RFPs generally don't work, unless an existing Debian contributor sees it and also has a need for the project.

Nothing prevents the ECharts project developers themselves to package Echarts and contributing the package to Debian, either by being sponsored by existing Debian Developers, or possibly becoming Debian Maintainers themselves, allowing them to upload a new package at any time without going through anyone else.
Post reply on HN