Live data from Hacker News

Apache ECharts

echarts.apache.org

71–80 of 263 posts

Re: Apache ECharts

#71

If you're looking for a chart library for a web client, I also recommend charts.css. It's a godsend honestly, the concept is way simpler than most charts libraries and can achieve the same thing. Makes it so simple to use the old way, server side rendering, htmx, etc... https://chartscss.org/

Chart css is like any of the other numerous libraries that can draw a line chart. It is a world apart from echarts.

Re: Apache ECharts

#72
post #70
post #55

Earlier quoted context omitted.

What about D3js? I know that D3js is low level, but with AI it's pretty easy.

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…

There's Plot, which is as standalone as anything[0]. That said, I still find D3 unparalleled in depth and scope.

[0]: https://github.com/observablehq/plot

Re: Apache ECharts

#73
Echarts can correctly animate data thats streaming via a moving window from right to left. Some other libs have issues in this case.

Re: Apache ECharts

#74
I'll toss some props to `go-echarts` [1], which allows you to declare charts with Golang types and it all gets bound to JSON automagically by Golang's JSON marshaller. I've used it for many projects and whenever there's an issue/PR, the maintainer responds quickly.

It's fun to Go-embed JavaScript functions and SQL queries, for this weird blend of data, SQL, Go and Javascript. Here's a Golang example that pulls data from a DuckDB and creates a baked-in candlestick chart file with JavaScript tooltips. [2]

[1] https://github.com/go-echarts/go-echarts

[2] https://github.com/NimbleMarkets/dbn-duckduck-goose/blob/mai...

Re: Apache ECharts

#76
post #70
post #55

Earlier quoted context omitted.

What about D3js? I know that D3js is low level, but with AI it's pretty easy.

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…

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 to attack observable since everything they put out is fully open-source. It’s not like they’re hiding docs behind a paywall, they’re actively contributing to the viz ecosystem through basically everything they release (eg Observable Plot, Observable framework).

As far as echarts goes, it’s a great tool. The declarative syntax for charting always feels a bit odd, but it’s easy enough to wrap into component libraries. AFAIK it still powers many of the big BI viz tools used today (eg AWS Quicksight).

Re: Apache ECharts

#77
We are actually using Apache ECharts to visualize system performance data in real-time using eBPF.

We had to do a bunch of stuff on top of it to get it working but all in all pretty nice.

You can check it out here in our sandbox:

https://yeet.cx/play

Re: Apache ECharts

#78
Anybody have experience using echarts with Vue 2.6? This looks way easier to implement than chart.js, but I’m worried about compatibility with such an old Vue build.

Re: Apache ECharts

#79
No opinion on this particular package. But on the naming, "Apache" ECharts...

It's long since time that Apache foundation projects stop using the Apache name. Apache is a license, a foundation, a webserver. Apache supported projects have little to do with that - not the same people, not the same product area. Just some help with money and logistics.

And for those that argue the tie to the Apache org:

They're not CNCF Kubernetes, CNCF Helm, CNCF Jaeger. They're Kubernetes, Helm, Jaeger.

Re: Apache ECharts

#80
post #76
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…

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…

Look, it’s not “bizarre” to point out that Observable has deeply shaped the modern D3 ecosystem. The issue isn’t that the D3 API has changed, it’s that a huge number of learning resources, examples, and docs have been rebaked into Observable’s reactive notebook style, which, for people not using Observable, adds a ton of indirection and mental overhead.

You might not notice it if you already know D3 inside and out, but for newcomers, it’s a bit of a turnoff. It’s ok if you like it though!

And no, this isn’t about “blindly copying and pasting.” It’s about people wanting to use D3 without having to learn an entirely different execution environment. That’s a reasonable boundary to set, especially when time and focus are finite.

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.

Post reply on HN