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

251–260 of 263 posts

Re: Apache ECharts

#251

Post by jwilber »

listenallyall wrote: post #239
jwilber wrote: post #107

Earlier quoted context omitted.

"You can use as many italics as you want but I don’t think it’s a wildly bold claim and your counter example is simply silly." I don't understand the relevance of any of this, but I think I've done a fair job outlining my points above. Let me give my best summary: the execution environment used by a library's (example) documentation is independent from learning the API of the library itself. I agree that newcomers to…

> But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all This is the core point. Yes of course the existing d3js docs are better than nothing. That isn't the complaint. The complaint is the current docs are significantly worse than older d3js docs that weren't notebook-based.

Can you provide an example? I’ve been using d3 on-and-off for almost 10 years, and the core docs have just gone from README’s to static-hosted pages with the same (version-specific) content (eg https://d3js.org/d3-selection/selecting). What is significantly worse here between the two? To my eyes, they’re basically identical: https://github.com/d3/d3-selection/tree/86

My best guess is that you’re referring to bl.ocks.org, which hosted d3 examples as standalone html examples, but this was independent from the d3 docs.

Re: Apache ECharts

#252

Post by captainmuon »

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…

It's not about the Apache web server, and I know there are a lot of actively maintained and respected projects under the Apache label (Lucene, Tomcat, Maven, ...).

I think the project that gave the most sour association was OpenOffice, which was donated to Apache when it was already over and the LibreOffice fork was well underway, and it has been on life support ever since. I recall there were a couple other projects with a similar fate but to be honest it is probably more of a brand reputation thing than an assessment of the quality of every project.

Re: Apache ECharts

#255

Post by pabs3 »

teddyh wrote: post #250
pabs3 wrote: post #245

Earlier quoted context omitted.

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.

True, but it is unlikely they would work on that. Usually upstream developers prefer people to not use distros to get binaries of their code. They already have an npm package and suggest people use it, there isn't much point additional external packaging systems after that. Also, packaging JavaScript/TypeScript stuff for Debian isn't trivial due to the volume of dependency packages that are typically not yet packaged, and other issues.

https://wiki.debian.org/Javascript

Re: Apache ECharts

#256

Post by infecto »

jwilber wrote: post #251
listenallyall wrote: post #239

Earlier quoted context omitted.

> But I'd prefer to have D3 documentation in the form of free, interactive Observable Notebooks rather than to have no documentation at all This is the core point. Yes of course the existing d3js docs are better than nothing. That isn't the complaint. The complaint is the current docs are significantly worse than older d3js docs that weren't notebook-based.

Can you provide an example? I’ve been using d3 on-and-off for almost 10 years, and the core docs have just gone from README’s to static-hosted pages with the same (version-specific) content (eg https://d3js.org/d3-selection/selecting ). What is significantly worse here between the two? To my eyes, they’re basically identical: https://github.com/d3/d3-selection/tree/86 My best guess is that you’re referring to bl.ocks…

The issue isn’t that the API documentation has disappeared, it’s that the learning experience for newcomers has degraded. The Observable-first direction has made it significantly harder for new users to grok D3 without buying into an entirely new runtime and mental model. Yes, the docs are technically still there, but they’re increasingly fragmented, and many examples now assume you’re using Observable or some variation of its reactive notebook model.

Bl.ocks.org wasn’t officially part of the D3 docs, but it played a critical role: it was the on-ramp. People learned by tweaking examples, not by reading method signatures in isolation. Saying people just want to “copy-paste” kind of misses the point, examples are how many developers build actual understanding. They’re not just blindly pasting code; they’re reverse-engineering patterns, figuring out how the pieces fit together.

We get it — you enjoy the library. But many users don’t appreciate the direction it’s taken. Such a bizarre defense. I guess we are not supposed to look at the examples when trying to grok a new library, especially a library for chart visualizations which is historically not known to be the easiest to work with.

Re: Apache ECharts

#257

Post by hustcc »

hamsterbase wrote: post #195
nchmy wrote: post #152

Earlier quoted context omitted.

Link here, for reference. https://github.com/antvis It seems good, but their docs websites are absolute trash (though they've seemingly gotten somewhat better recently - they were previously completely unusable). e.g https://g6.antv.antgroup.com/ Overall, I think you cant go wrong with Apache.

There's one more thing. Leader of antv is the developer of echarts.

[dead]

Re: Apache ECharts

#259

Post by jitbit »

lucasfcosta wrote: post #133

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

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

Post reply on HN