[HN Gopher] Apache ECharts
___________________________________________________________________
Apache ECharts
Author : tomtomistaken
Score : 600 points
Date : 2025-04-08 17:23 UTC (5 hours ago)
(HTM) web link (echarts.apache.org)
(TXT) w3m dump (echarts.apache.org)
| jollyllama wrote:
| Looks like it could work nicely with HTMX.
| wlkr wrote:
| Funny seeing this here with your comment, as I was exploring
| using ECharts for a project recently to work exactly with HTMX
| from a Clojure backend. I eventually settled on Chart.js as I
| found that for my use case, I wanted the charts to more easily
| fit their dynamically sized container, which isn't quite as
| simple with ECharts and Vega. I also didn't need particularly
| complex plots. Nevertheless, this is a nice project! There
| remain some open challenges with web-based visualisation
| libraries more generally around responsive design and
| accessibility, but we've come a long way.
| simlevesque wrote:
| Did you look at charts.css ?
|
| https://chartscss.org/
| jollyllama wrote:
| > more easily fit their dynamically sized container
|
| I've done this for more simpler elements. Copilot helped me
| come up with a little bit of custom JS in those cases.
| TechDebtDevin wrote:
| I've been meaning to practice some data visualization tasks... If
| anybody knows any cool datasets they'd recommend that aren't your
| run of the mill kaggle consumer data or whatever. I'm
| particularly interested in bioinformatics/genetics data but not
| really sure of where to look (and have almost no background, just
| personally interested in comp-bio).. If anyone could recommend
| cool and open esoteric data/possible projects, that would be
| awesome.
| cess11 wrote:
| Could try these:
|
| https://www.ncbi.nlm.nih.gov/datasets/
|
| https://github.com/OpenGene/awesome-bio-datasets
| FredPret wrote:
| The line race looks so cool.
|
| https://echarts.apache.org/examples/en/editor.html?c=line-ra...
|
| Toggle the switches to trigger the race. By the way, well done
| Norway.
| rrr_oh_man wrote:
| Props to Hans Rosling I think:
|
| https://www.youtube.com/watch?v=hVimVzgtD6w (2003)
| vecinu wrote:
| Something's off here. The data appears as "life-expectancy-
| table.json" but the title refers to Income. Not sure where the
| mistake is.
| macNchz wrote:
| The source data, despite the filename, contains Income, Life
| Expectancy, and Population by Country+Year:
| https://echarts.apache.org/examples/data/asset/data/life-
| exp...
| NicuCalcea wrote:
| 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
| razemio wrote:
| 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 base just existing because of
| this animation.
| JacobiX wrote:
| In a quick web demo, this library was the only one that could
| handle interactive viewing and manipulation of a very large graph
| using its GraphGL component ! I don't think it's a well-known
| visualization library, but it's quite interesting ...
| wackget wrote:
| I'd really like to know how they did all the transition effects.
| They were really cool.
| nylonstrung wrote:
| What does this have over Plotly, Chart.js, D3, Bokeh, etc
| sergioisidoro wrote:
| A very large library of premade charts for web. Probably the
| largest I've seen. Less customizable than chart.js, and D3 is
| more of a rendering library than a charting library.
| secos wrote:
| I'd forgotten all about this library, its certainly come a
| long way!
| AntonyGarand wrote:
| I'm surprised by your claim of it being less customizable
| than chart.js, it has been very flexible from my experience.
|
| It could rival d3 with a lot of customization and a worse DX
| from what I've seen: It's essentially a good amount of
| defaults, but you can override and replace essentially
| anything.
| darth_avocado wrote:
| Just a nit: the part that describes its mobile optimized (and
| pretty much all other pages describing the features) does not
| load correctly on mobile.
|
| https://echarts.apache.org/en/feature.html#mobile
| amanj41 wrote:
| Used this for some knowledge graph visualization work. Really
| clean UI and some nice features out of box for interactivity
| keithxm23 wrote:
| I was particularly impressed with how performant the demo was as
| it was playing. I was fully expecting my Macbook-fan to start
| whirring as it usually does with most javascript-heavy pages.
| 9283409232 wrote:
| I don't think I ever see Wechat and Weibo in the "Follow Us" box.
| Was this donated to Apache by a Chinese company? I feel like we
| will see a lot more of this in the coming years.
| devitx wrote:
| The library originates from a team of developer from a chinese
| Company (Baidu I think).
| jacksavage wrote:
| I saw that the rendering library for echarts, zrender, is
| managed by a GitHub org associated with Baidu
|
| https://github.com/ecomfe
| mediaman wrote:
| Agreed - geopolitics aside, it's been awesome to see how much
| Chinese companies have embraced open source in a number of
| different domains. I think the whole ecosystem is going to
| greatly benefit from the contributions of Chinese open source
| projects.
| skadamat wrote:
| Apache Superset switched many of their interesting charts over to
| ECharts:
|
| https://preset.io/blog/2021-4-1-why-echarts/
| frogperson wrote:
| Thank you, I thought these looked familiar somehow.
| grzaks wrote:
| Superset[1] BI tool is a good example of how useful ECharts are
|
| [1] https://superset.apache.org/
| mritchie712 wrote:
| we use eCharts for all the visualizations in
| https://www.definite.app/.
|
| We evaluated pretty much every option and it's the best non-react
| option. Recharts honestly seems a little nicer if you're using
| React, but our frontend is in Vue.
| Octoth0rpe wrote:
| Even if one is using react, I think there's value in choosing
| libraries that are not deeply tied to react such that that
| logic can be reused when (not if) we need to start migrating
| away from it.
| cyral wrote:
| The problem is non-react chart libraries can be a bit
| cumbersome to use in React. For example, D3 controls the DOM
| itself through various transformations. React is not aware of
| these updates and combining react's state based DOM
| manipulation with random updates from a charting library gets
| messy.
| XCSme wrote:
| How does it compare to https://www.chartjs.org/ ?
| go_prodev wrote:
| It's much heavier but a lot more powerful and flexible.
| XCSme wrote:
| Thanks! And is it more or less performant on large datasets
| (100k+ data points).
| etimberg wrote:
| maintainer of chartjs here.
|
| It's probably more performant. Chart.js isn't designed for
| a ton of data and we recommend sampling before
| visualization . We have a builtin plugin that does a form
| of min/max sampling to retain peaks but cut down on the
| amount of data points drawn
| rudasn wrote:
| Hey! Thanks for maintaining chartjs :)
| simlevesque wrote:
| 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/
| paulirish wrote:
| In the same vein, I've long had a soft-spot for the JS-enhanced
| https://pancake-charts.surge.sh/ (developed by NYT graphics
| team and used for the covid charts).
| Eduard wrote:
| The animation examples for chartscss are annoying. it doesn't
| look nearly as functional
| homebrewer wrote:
| > can achieve the same thing
|
| Did you even look at echarts demos, or amcharts demos for that
| matter -- it's basically the same thing, but paid for:
| https://www.amcharts.com/demos ?
|
| I don't have anything against charts.css, but it's like
| comparing a children's plastic toy to a real space shuttle. I
| spend most of my work hours developing a heavy business
| analytics application (not unlike Apache Superset), and it
| would simply be impossible to implement it with something like
| chart.css
| infecto wrote:
| Chart css is like any of the other numerous libraries that can
| draw a line chart. It is a world apart from echarts.
| xiaoyu2006 wrote:
| Pleasing visual which had my browser's FPS went low, especially
| at the liquid fill extension part.
| paulirish wrote:
| Impressive work! Their main demo there pays some homage to Mike
| Bostock's d3 transitions showcase from 2011:
| https://mbostock.github.io/d3/talk/20111116/transitions.html
| (click to start)
| forthwall wrote:
| I love echarts, I've used it at almost every company I've worked
| at to this day since I found it.
| bzmrgonz wrote:
| how long ago did you find it? Maybe you can share the dev
| progress if it was a few years back.
| the_arun wrote:
| Reminds me of https://d3js.org/
| jjmarr wrote:
| Are ECharts safe for untrusted user input?
| lxe wrote:
| What a complete exhaustive set of examples! Very useful. Both SVG
| and Canvas renderers differ very little and both seem to be super
| performant. The declarative API is just so simple... harkens back
| to the age of batteries-included web frameworks like Ext.
| smashah wrote:
| Sorry if this is a silly question but how does a project become
| "Apache"? Like is there a core team starting these projects or is
| there an application process for a project to be under the Apache
| banner?
| SoftTalker wrote:
| I believe it's the latter.
|
| https://incubator.apache.org/
| OsrsNeedsf2P wrote:
| The only thing I ever want out of these chart libraries is to be
| able to theme them. Does anyone know how customizable the theming
| for ECharts is?
| iamsmooney wrote:
| It might be able to:
| https://echarts.apache.org/en/option.html#color
| harunurhan wrote:
| I was curious about this too, and I found
| https://echarts.apache.org/en/theme-builder.html
| rorylaitila wrote:
| ECharts is in my opinion the best out there. It surprisingly
| doesn't come up in a lot of lists or search for charting
| libraries. I've tried them all: chart.js, google charts,
| amCharts, Highcharts, ApexCharts. We use it in our tool/library
| https://docs.chartsql.com/
| abirch wrote:
| What about D3js? I know that D3js is low level, but with AI
| it's pretty easy.
| infecto wrote:
| 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 seriously obfuscated how to use d3 itself.
| dleeftink wrote:
| 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
| jwilber wrote:
| 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).
| infecto wrote:
| 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.
| abtinf wrote:
| Pre-observable, I used d3 to develop a very complex
| visualization with real-time updates. It was difficult
| because d3 has a lot well-thought-out-but-complex
| concepts, but the docs and examples helped me fully
| understand how it worked, and the result turned out
| spectacular.
|
| A few years later, I needed to build a simple novel
| visualization. A major new version of d3 had come out,
| and all the examples and documentation got Observable-
| ified.
|
| Enough time had passed that I could only vaguely recall
| some of the original concepts, so I set out to re-learn.
| YMMV but, for me, it was impenetrable. With the limited
| time I had, I just couldn't figure out how to untangle d3
| from observable. I gave up. Very sad.
| jwilber wrote:
| "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 JavaScript may find plenty of confusion
| there, and I'm sure a decent chunk of D3's users may be
| new to web-programming in general, but it's not the job
| of D3 maintainers to account for that.
|
| I actually think our back-and-forth is a perfect example
| of why open-source is so painful to work on.
|
| D3 is one of the best documented libraries out there is.
| There are multiple books, hundreds of hours of youtube
| videos, and most importantly, dedicated maintainers (Mike
| Bostock, Philippe Riviere, etc.) who've poured hours into
| additional sources of documentation and are very
| responsive on GitHub issues.
|
| The unfortunate outcome here is that users have come to
| _expect_ this sort of high-quality support and
| documentation (again with the italics, who does this guy
| think he is???). Every D3 submodule has standard api
| documentation, sure, but thats expected of all libraries
| these days. However, the additional example documentation
| (again, nobody got paid to make this material) for the
| most recent releases has been migrated from bl.ocks.org
| (a now defunct open-source service users didn 't pay for
| it) to Observable Notebooks. Now, Observable is a VC-
| backed business, yes, but the documentation is still
| completely free. In this thread, you mention you don't
| like this, so in at least one online conversation where
| D3 comes up, you actively advocate against using it _out
| of principle_! (Couldn 't resist!).
|
| Of course this is just my viewpoint on what has
| transpired, and I'm likely articulating it in a more-
| inflammatory-than-reality manner. But I'd prefer to have
| D3 documentation in the form of free, interactive
| Observable Notebooks rather than to have no documentation
| at all. Even more so if it helps out the authors of the
| open-source library.
|
| As a tip for those who have difficulties going from the
| reactive Observable model to vanilla js -> you can always
| just take an observable notebook and ask AI to convert it
| to a set of vanilla files for you.
|
| PS - Sorry for the novel, at an airport!
| infecto wrote:
| Appreciate the lengthy response, but I want to clarify a
| few things since I think my original point keeps getting
| mischaracterized.
|
| First, the italics. You opened with "This is a very
| bizarre take"--emphasis on very--which, whether you
| intended it or not, sets a smug tone. It's the kind of
| rhetorical move that shuts down discussion before it
| starts. I'm not saying this to nitpick style, but to
| point out how quickly this moved from a discussion about
| tooling to a dismissal of my viewpoint. It is an easy
| tell the person writing gives away when they use it like
| you do.
|
| Now, to the substance: yes, the D3 API is technically
| independent of Observable. But in practice, Observable is
| now the primary medium through which new users encounter
| and learn D3. The official examples, new documentation,
| and most teaching material are embedded in the Observable
| environment, which introduces its own model of
| reactivity, syntax, and execution. That's not a minor
| detail, it's a real obstacle for people who just want to
| understand and use D3 in plain JavaScript.
|
| Your PyTorch/mkdocs analogy completely misses the mark.
| Mkdocs is a static site generator. It doesn't change the
| code you're learning--Observable, on the other hand,
| does. You can't meaningfully learn D3 from many of these
| new examples without understanding how Observable cells
| work. That's a tight coupling, and one I don't think
| should be hand-waved away.
|
| "Just use AI to convert the notebook" is a non-answer. It
| assumes everyone is okay with outsourcing understanding
| to a black box just to get a usable snippet. That's
| exactly the kind of indirection I'm objecting to in the
| first place.
|
| Lastly, yes, I've set a personal boundary: I don't want
| to buy into an ecosystem that made a choice I don't
| support. That's not a call to boycott, it's just me
| saying, this direction doesn't work for me. If that's
| enough to dismiss my view as bizarre, then I'm not sure
| what kind of discussion is even possible here.
| 9dev wrote:
| 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 problem is that D3 resources mix D3 documentation
| with demos of D3 itself, and demos of Observable, into a
| single, inseparable combination. Nobody would complain
| were those three things separate resources; alas, they're
| not.
|
| Every time someone raises this issue, they are shot down
| by people like you, with the same nonsensical argument--
| just because the maintainers write cool demos in a fringe
| datavis DSL, that doesn't automatically mean it's helpful
| for the 99% use case of rendering charts in normal apps.
| mkl wrote:
| > it's odd to attack observable since everything they put
| out is fully open-source
|
| Really? They've finally open-sourced the notebook editor?
| I can't find it on their GitHub. The long-proprietary
| notebook editor is a big part of people's objections to
| Observable.
| kowlo wrote:
| It's a shame - and I'm not sure why they did it other than
| to use D3.js' popularity promote Observable.
| rorylaitila wrote:
| We needed charting for ad-hoc business reporting from SQL.
| ECharts was at the right level of ease of use and available
| charts, interactive, and looks great right out of the box.
| ActVen wrote:
| I used to love using it. But, all of my coworkers hated it. I
| haven't revisited since the AI boom. Maybe it will have a bit
| of a comeback. Many people found it too difficult.
| kowlo wrote:
| Not touching D3.js since Observable.
| eigenvalue wrote:
| I think that's because it's a Chinese Project. Same thing with
| Ant Design Components, which are really awesome but not as well
| known as they should be.
| sdesol wrote:
| I think it being Chinese is part of the reason as some of the
| examples in the early days were Chinese only, which could
| deter some people. It is certainly more complex (for a good
| reason in my opinion), I can see why it is not well known
| since I think the vast majority just wants to create simple
| charts. However, with echarts, it really can meet Enterprise
| needs.
| rorylaitila wrote:
| Yeah that might be why. A couple years ago I was trying to
| find "this cool charting library" I came across and I could
| not get it to surface in Google.
| RowanH wrote:
| Oooo thank you for mentioning that. Looks quite feature rich
| !
| RedShift1 wrote:
| I like Plotly.
| rorylaitila wrote:
| I took a look at Plotly but ultimately wanted a Js solution
| for our Java backend, so that we can run our SQL charts layer
| on GraalVM.
| skeeterbug wrote:
| They publish plotly.js and react bindings as well.
| vkaku wrote:
| This is great. I was always looking for a well licensed library
| that is well maintained and ships a coherent featureset. This
| seems to tick all the boxes.
| geysersam wrote:
| Do anyone have experience with this in comparison to vega?
| arsalanb wrote:
| We use Vega pretty heavily, its a broader ecosystem. Where it
| really shines is in combination with Altair and Vegafusion to
| do number-crunching on the backend and return a chart spec that
| can just be rendered on the front-end.
|
| That makes it particularly useful when building interactive
| visualizations with a lot of data.
| bawolff wrote:
| As an aside, wikimedia is switching all their chart support
| from vega to echarts.
|
| I'm not an expert on either, but my impression is that vega
| tries to do literally everything using a custom json syntax
| which can get confusing and unwieldly. Echarts is a bit more
| straightforward at least for the simple case.
|
| Vega has a questionable security track record which is
| concerning if you let untrusted users define graphs.
| smjburton wrote:
| I was just looking into charting libraries for React/React
| Native, and Apache ECharts seems like a great contender for
| cross-platform data visualization. The libraries that I came
| across - react-echarts (https://github.com/hugocxl/react-echarts)
| and react-native-echarts (https://github.com/wuba/react-native-
| echarts) - both seem to be actively developed, and the fact that
| it's under Apache is a huge plus for future development prospects
| and maintenance of the project.
| bzmrgonz wrote:
| what happened to sankey? no sankey graph??
| Octoth0rpe wrote:
| echarts definitely supports sankey:
| https://echarts.apache.org/examples/en/index.html#chart-type...
| bzmrgonz wrote:
| they are missing the mark by not featuring it in their demo.
| The us national budget comes to mind as a feature clip in the
| demo for sankey.
| echoangle wrote:
| I don't get what you mean, it is featured in the demo. On
| the landing page, click demo and navigate to sankey in the
| menu.
| bzmrgonz wrote:
| sorry, I didn't see it in their featured demo video,
| unless it was shown supper quick.
| scottgpaulin wrote:
| ECharts powers all charts in tablab.app. Might be using 20
| different chart types or so
|
| Very happy with it.
|
| Theming works well (saw a question or two about that)
| numdefined wrote:
| We [1] use ECharts to visualize all of our data and it's pretty
| great to use.
|
| It's also very pluggable, so one can only import the components
| one needs for each chart. Meaning if you only use the `bar`
| series type, you can just only import the `bar` component. Same
| thing not only for other chart types but also stuff like mark
| areas or zoom controls.
|
| There's also a bigger update in the work which brings e.g. violin
| plots.
|
| [1] - https://donation.watch/
| evaneykelen wrote:
| After many trials with other libraries, my team settled on Apache
| ECharts last year, and we do not regret it: excellent
| documentation, performant, highly configurable yet easy to use,
| and supporting all the chart types we need (bars, stacked bars,
| maps, zoomable/scrollable time series, and scatter plots).
| nXqd wrote:
| how is it compared to ag-grid chart?
| evaneykelen wrote:
| We did not evaluate libraries that have a paid plan
| aargh_aargh wrote:
| What about Vega?
| rubyn00bie wrote:
| I like ECharts a lot and generally, it was incredibly easy to use
| and customize. I tried a lot of alternatives that weren't nearly
| as full featured. It's really got most anything you'd want
| included in outta the box.
|
| With that said, I had trouble getting it to stream updates, and
| was having big performance issues with the dataset I was throwing
| at it (full telemetry from a racing sim roughly every 12ms). I
| did not make any attempt to refine the data before delivering it
| so YMMV. I eventually switched to Plotly and D3 to get better
| performance, but definitely missed the ease of use.
| je42 wrote:
| Echarts can correctly animate data thats streaming via a moving
| window from right to left. Some other libs have issues in this
| case.
| neomantra wrote:
| 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...
| TheGoodBarn wrote:
| This is so sick thank you for sharing. I do a lot of Go +
| DuckDB stuff. I've done some janky JS / html/template stuff for
| charting so this will be fun to play with
| amcaskill wrote:
| We use ECharts extensively in Evidence
| (https://github.com/evidence-dev/evidence). Overall has been a
| delight.
| hughess wrote:
| Examples from this fairly custom implementation:
| https://docs.evidence.dev/components/all-components/
| r3tr0 wrote:
| 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
| Game_Ender wrote:
| Getting a 503 with that link.
| perdomon wrote:
| 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.
| nkmnz wrote:
| Used it extensively with Vue 2, never had any compatibility
| issues. Moved on to Vue 3 by now, though.
| nkmnz wrote:
| Btw, if you're looking to migrate to Vue 3, hit me up on
| github. Handle is the same as it is here :)
| jlaporte wrote:
| 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.
| abtinf wrote:
| > They're not CNCF Kubernetes, CNCF Helm, CNCF Jaeger.
|
| Maybe they should be?
| miiiiiike wrote:
| 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.
| greenavocado wrote:
| How is the Apache project still alive? Who funds them?
| henning wrote:
| ECharts was handy for getting a quick chart going in a typing
| practice app I wrote. It was easy to get a chart showing WPM over
| time on a word list.
| floppydiskette wrote:
| Related, I just wrote an article and demo about enabling Apache
| ECharts in React[1] this week.
|
| [1] https://tania.dev/apache-echarts-react/
| mceoin wrote:
| We [1] just added to ECharts as a charting library for our AI and
| are switching the default GUI charts over to it as well. We did a
| pretty extensive review before selecting it. ECharts won because
| it's excellent, and very pretty.
|
| 1. https://sourcetable.com
| pmarreck wrote:
| Your product looks great. Do you have an open-source or self-
| hosted version for companies with strict security requirements?
| mceoin wrote:
| Not presently. We'll do an enterprise push at a later date.
| givemeethekeys wrote:
| Is it Vibe Coding friendly?
| techscruggs wrote:
| I've been using apache echarts for a while. It is excellent. As
| you dig deep, some of the examples and libraries are in Chinese,
| which can be challenging.
|
| The only real drawback that I've discovered is that it uses
| canvas to generate the charts. So, when you UI changes to dark
| mode, you need to reload your charts to update the color scheme
| ... which in the grand scheme of things is really minor.
| elAhmo wrote:
| The demo is seriously impressive! I haven't heard of this library
| before, will definitely consider using it
| DadBase wrote:
| I've had good luck generating charts with gnuplot and serving
| them as static images--keeps things simple and easy to cache.
| Haven't had a need for a full JS charting library yet, but I can
| see the appeal.
| _nickwhite wrote:
| This is super slick. I remember spending _hours_ maybe days
| trying to make MRTG or rrdtool graphs look like these.
| gerash wrote:
| what's the best way to use a JS visualization library like this
| while using python for data extraction / manipulation in a
| notebook format (eg. Jupyter notebook, Google Colab, etc.) ?
___________________________________________________________________
(page generated 2025-04-08 23:00 UTC)