[HN Gopher] Apache ECharts
___________________________________________________________________
Apache ECharts
Author : tomtomistaken
Score : 1534 points
Date : 2025-04-08 17:23 UTC (1 days 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/
| wlkr wrote:
| This looks great, thanks! I didn't come across this this in
| my search but I'll definitely try it out.
| 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.
| dismalaf wrote:
| Not sure about HTMX specifically, but I've used it with
| Rails/Hotwire/Stimulus (similar conceptually) and it works
| great.
| anentropic wrote:
| I'm using ECharts with HTMX + AlpineJS, with ECharts wrapped in
| an Alpine component
|
| I had to disable hx-history to get around a problem of the
| charts getting double instantiated
|
| it feels a bit of a lame workaround but I never managed to get
| to the bottom of it
|
| apart from that, totally happy
| 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
| TechDebtDevin wrote:
| Thanks!
| 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.
| noduerme wrote:
| Not completely unrelated, the mechanical horse race game
| that used to be at The D in Vegas, and now is at the Linq
| (I think?) has a similar effect on the human psyche. As
| does gambling on most sporting events. Anything with a lot
| of ups and downs. I really started to think about this when
| I was developing casino games about 15 years ago. But the
| same is true with any game, or any future event. When an
| outcome is unknown, we experience time as a set of discrete
| emotional peaks and valleys - we experience an extra
| dimension of time, the high/low. Apart from being a highly
| successful design hook, I think it can be a really powerful
| way to encode information. Especially if you have time-
| referenced data and you've already exhausted the other axes
| or relative sizes you might use to convey your dimensions.
| Like, my main argument with using that "race" is that you
| could use the x-axis for something else, and have the whole
| graph change over time.
|
| But you're very right that this indeed relies on an
| emotional component to achieve the full effect of conveying
| time in two dimensions. If there's no emotional attachment
| to the outcome, our brains don't process the highs or lows.
| In that case, a variance chart like open/close prices on
| the stock market might work better.
| kortilla wrote:
| These channels don't exist because it's a better way to
| display information. It's a more click bait way.
|
| 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.
| dijksterhuis wrote:
| it would get the point across much faster. but it would be a
| less enjoyable interaction. this is an example graph that i'm
| never going to look at ever again. i don't even need to care
| about information. like, it's mostly irrelevant to me. it's a
| toy example. and it's a bit of a fun example to make people
| go 'huh, this is a cool vizualisation package'.
|
| if i had a dashboard i needed to use at _work_ set up like
| that i 'd have a bloody conniption after a week. but this
| isn't a work dashboard -- it's a functionality demo and i'm
| more likely to remember echarts now as a result (purpose of
| examples achieved).
| FredPret wrote:
| 1. The race animation adds no information, but better
| communicates the idea that we're looking at a series of
| moments in time, each with its own history and emotional
| impact. Watching the lines race shows us what it would've
| felt like looking at this graph during each year.
|
| 2. The Chartjunk wiki cites Adolf Loos's idea "ornamentation
| is a crime". But I think we're done with modern minimalism
| and in the process of rediscovering the joy in ornamentation.
| This is an aesthetic choice and you may disagree.
|
| https://en.wikipedia.org/wiki/Ornament_and_Crime
| NiloCK wrote:
| At the risk of piling on (others have commented), I'll go so
| far as to say that there really is more information here if
| you make the gentle assumption of a human observer.
|
| In the animated version, a human observer here is allowed
| (forced) to occupy mental states of a real-time observer.
| They have the experience of "X has jumped ahead - I wonder if
| it'll last - oh, wow, Y is really surging".
|
| The visceral experience matters, and is impossible to
| recreate post-hoc if all of the info is presented up front.
|
| (edit: "more information" in so far is it informs more -
| leaves more impressions on the observer)
| bjarneh wrote:
| > 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.
| helloplanets wrote:
| 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.
| gadders wrote:
| >>By the way, well done Norway.
|
| I wonder how well it correlates with the oil price.
| 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.
| ranger_danger wrote:
| Can you name one thing that chart.js does that Apache ECharts
| cannot do?
| skadamat wrote:
| I wrote a bit about that here:
| https://preset.io/blog/2021-4-1-why-echarts/
| 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.
| throwaway290 wrote:
| It is a country with public adverts explicitly saying
| "America/west is the enemy". Supply chain attacks via open
| source are already happening.
| throwaway290 wrote:
| It's made by Baidu and Apache is sponsoring them (why I don't
| know, Baidu must have enough money right?)
| 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.
| adeptima wrote:
| Look at Superset chart implementations and component choice all
| the time.
| 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 :)
| leeoniya wrote:
| maintainer of uPlot here :)
|
| they're about same for line chart rendering when using
| decimation in both.
| XCSme wrote:
| Wow, that's cool, thanks for working on it, I've been
| using Chart.js for many years :)
|
| Performance seemed quite good with Chart.js in my case,
| for small to medium datasets.
| joshkel wrote:
| The biggest difference I'm aware of is that ECharts has an add-
| on for 3D charts (echarts-gl). Chart.js doesn't have any 3D
| functionality.
|
| (Our project mostly uses Chart.js, so I'm more familiar with
| it.)
| 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).
| tkcranny wrote:
| Thought that felt very "Svelte-like". And of course, turns
| out it was by Rich Harris himself back when he was at the
| NYT.
|
| Beautiful charts, shame it looks defunct now.
| 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.
| anentropic wrote:
| While I agree with other replies that ECharts provides a lot
| more functionality than this lib, it does look very nice the
| way it transforms a semantic table of data into the chart!
|
| I'm using ECharts (and happy with it) but there are some places
| where I want like a sparkline in every row of a data table,
| which is a lot of ECharts instances to instantiate, and this
| lib looks like it'd be great for that.
| didip wrote:
| The biggest problem with this is that you are representing
| points in DOM, just like SVG.
|
| If there are a huge number of datapoints, this library will
| paint itself in the corner.
| 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
| anentropic wrote:
| It's pretty extensively customisable
|
| Certainly colours, fonts and sizes are all configured at the
| 'theme' level, plus the charts themselves have a lot of visual
| variations to choose from
|
| I don't think you would have any problem making it fit with the
| style of your site
| 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
| josephg wrote:
| I used Plot for an academic paper I wrote recently. It
| was the only charting library that I found that let me
| generate the charts I wanted to draw - which in my case
| was a grouped bar chart with a logarithmic scale. Ie:
|
| https://github.com/josephg/egwalker-
| paper/blob/master/diagra...
|
| I didn't try echarts though. I might have to give it a go
| if its good.
| shiandow wrote:
| I reckon you can get something quite similar with
| matplotlib without too much trouble, though that strongly
| depends on how comfortable or familiar you are with it.
| 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.
| edoceo wrote:
| Same story here, landed on Apache Echart (it seems, like
| many others)
| 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.
| boomskats wrote:
| Entirely unrelated, but I've not heard anyone describe it
| as `outsourcing understanding` until now. That's a great
| phrase.
| kowlo wrote:
| > you can always just take an observable notebook and ask
| AI to convert it to a set of vanilla files for you.
|
| D3.js docs used to be fine. Now you need to "ask AI" to
| untangle them?
| listenallyall wrote:
| > 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.
| WuxiFingerHold wrote:
| I'm an experienced dev and looked seriously into D3 some
| month ago for the first time. I can confirm what you
| wrote. The notebooks feel like an unnecessary hurdle.
| It's not a big hurdle, but one that could be avoided so a
| slightly annoying experience.
| 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.
| the_real_cher wrote:
| 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?
| 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.
| smelendez wrote:
| Depends on the use case.
|
| If you're a data viz team and do this all the time, and
| everyone knows or is willing to learn D3, then sure.
| Otherwise, if you just need to add a graph to your website,
| you may find it slows you down and makes code less
| maintainable.
|
| I personally find it confusing and as others mentioned I can
| forget how it works over time, though I admire it. I don't
| think I could jump in and edit D3 code today without careful
| study, any more than I could jump in and edit Perl code.
| Echarts/Highcharts etc. are much more intuitive.
| 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
| !
| nchmy wrote:
| 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.
| hamsterbase wrote:
| There's one more thing. Leader of antv is the developer of
| echarts.
| nchmy wrote:
| really? how/why?
| ranger_danger wrote:
| A large number of developers/users of Apache ECharts also
| seem to be Chinese.
| athrowaway3z wrote:
| Time to put on a conspiracy hat.
|
| If you scroll down, the entire comment section reads a lot
| like a campaign to fix their search results & AI
| suggestibility.
|
| Way too many comments read like generic seller-inserted
| reviews, eg "Great Product!", "Tried X, Y, Z but this solved
| my problem!".
| 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.
| hajile wrote:
| I'm a big fan of VisX for the level of control it gives.
| chamomeal wrote:
| I love visx! Surprised to see your comment is the only
| mention of it here.
|
| I guess it's specifically a react library, but it's such a
| sweet spot of control and built-in convenience. Having all
| the annoying stuff like curves/axes/scales/shapes handed to
| you in a pretty un-opinionated way is really nice.
|
| I was at a startup for a few years and I built all of our
| client's dashboards in visx. I loved it from the first minute
| to the last, and have almost no complaints. And there are few
| few libraries I can say that about!
| rorylaitila wrote:
| VisX looks nice. We haven't had the need for more complicated
| visualizations yet but I'm always looking out for options.
| TN1ck wrote:
| Can recommend visx as well, it's great as it's basically a
| thin layer around d3, giving you maximum flexibility while
| providing lots of built in components to get you started.
| bezbac wrote:
| I can second this. VisX will be a little more effort but it
| will let you build anything you could build using d3.
| 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.
| echoangle wrote:
| It's not in the demo video, but it's in the demo gallery.
| That's also the thing that's linked as "demo" on the
| landing page, so I thought you were talking about that.
| 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
| rochak wrote:
| Now that's incredible
| 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/
| stoicjumbotron wrote:
| Such an amazing project! Although I don't have any use case as
| of right now, will definitely keep this one in mind.
| notimetorelax wrote:
| Thanks for sharing, evidence looks very interesting. Reading
| the docs, do I understand it right that I need to publish
| parquet files so that WASM DuckDB could query them. I'm a bit
| concerned users wholesale downloading all the data.
| 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.
| captainmuon wrote:
| 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".
| greenavocado wrote:
| How is the Apache project still alive? Who funds them?
| mr_toad wrote:
| https://www.apache.org/foundation/sponsors
| 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?
| uwemaurer wrote:
| Echarts has good documentation and examples so I think it
| should be vibe coding friendly when you reference the docs (eg
| with cursor)
| anentropic wrote:
| I've found ChatGPT reasonably good at giving me working ECharts
| configs...
| 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.) ?
| ddanieltan wrote:
| might want to give https://pyecharts.org/#/ a try. After data
| manipulation in a notebook, import pyecharts and use their api
| to create an echart
| mt_ wrote:
| The AWS Quicksight BI tool uses it underneath.
| cwillu wrote:
| I really wish the "slowly fade elements in as they scroll onto
| the screen" would die.
| lucasfcosta wrote:
| 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 the declarative spec for the graphs
| in the back-end and then only send the desired spec to the front-
| end so it can render, and it's also extremely flexible to the
| point we can support everything that traditional BI tools can do.
|
| We've never had to extend the lib to do anything new, everything
| we need is already there.
|
| Glad to see this great piece of work on top of HN.
| stuartaxelowen wrote:
| Did you compare to vega/vega lite? Curious to hear how they
| compared!
| spaceribs wrote:
| 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 for my
| visualization. The reality is that not enough other people
| are willing to put in the effort to learn that syntax, making
| it somewhat of a selfish tech choice.
| RobinL wrote:
| As a big user of vega lite I think that's fair. I think it
| really shines when used by data vis experts, where charts
| need to be precise, such as in research and analysis
| contexts. For something like a simple a metrics dashboard I
| think I'd agree that it may be difficult for devs.
| noduerme wrote:
| I must've looked at this years ago, but for whatever reason,
| hitched my wagon to Chart.js and haven't really needed anything
| it couldn't do. And that's for weird one-off custom stuff. For
| business analytics I just self-host a Metabase server. I wish
| there were more visualization options with Metabase, but it's
| such a cinch to set up models and queries. But I don't often
| get a visualization request that justifies the time to create a
| custom chart.
| naught0 wrote:
| I recently had the need to create a gradient line chart with
| each step on the y-axis representing a color which should blend
| with its neighbors, and echarts was the only option that made
| sense to me after trying a few. The lack of obvious react
| integration initially put me off, but like any js lib it was
| pretty easy to use anyway. Echarts surprised me - it's great.
| adeptima wrote:
| same experience
| zwnow wrote:
| How is it better than Chart.js? Im curious as the
| implementations look extremely similar.
| anentropic wrote:
| One consideration I looked at when choosing between them was
| I believe chart.js is Canvas-only, whereas ECharts can output
| SVG
|
| for millions of points maybe Canvas rendering is more
| performant
|
| but for simple charts SVG provides an easier way to get
| responsive sizing just via CSS without involving JS to re-
| render
| zwnow wrote:
| Hmm I see, will try the apache one, thanks for the input
| zurfer wrote:
| I can't agree with that. eCharts is good, but
| https://plotly.com/javascript/ is also super nice and I am
| actively following https://observablehq.com/plot/ which seems
| on a path to true greatness.
| ramonverse wrote:
| Plotly is full of undocumented features. My guess is because
| they have an entire consulting business helping devs with
| this
| incoming1211 wrote:
| 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.
| disgruntledphd2 wrote:
| 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.
| hajile wrote:
| 22.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?
| infecto wrote:
| In fairness that would be all the charting options baked in.
| Typically you only install the specific charts you are using.
| frainfreeze wrote:
| Not that big if you pick just what you need (but still quite a
| lot of kb to be fair). Take a quick look at their online
| builder and test it for yourself
| https://echarts.apache.org/en/builder.html
| aitchnyu wrote:
| Umm, minified version from site is 335.50 kB gzipped /1.03 MB.
| anentropic wrote:
| The lib is modular
|
| My current build for an analytics dashboard app uses:
| echarts.use([ // chart types: BarChart,
| LineChart, GaugeChart, PieChart,
| // chart features: TitleComponent,
| LegendComponent, TooltipComponent, // ~30kb
| GridComponent, // ~100kb, controls layout (not visible grid
| lines) LabelLayout, DatasetComponent,
| // renderer: SVGRenderer, ]);
|
| ...and comes out at 550kb minified but unzipped
| King-Aaron wrote:
| I've probably used Apache e-charts in some way or another in
| every project I've been on in the last decade. One of those
| packages that just works out of the box.
| d_t_w wrote:
| 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
| ingen0s wrote:
| Times sure do change - nice acquisition- hope it stays open
| prabhatsharma wrote:
| We moved from plotly to eCharts at OpenObserve, having faced too
| many small things that we had to fight with plotly. Haven't
| looked back since the migration.
| lucb1e wrote:
| Noticed 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 looking at the basic
| scatter plot functionality, since I use that most often), I can't
| seem to tab or otherwise navigate through the data points, so it
| may just be impossible to get the data read out to you like
| "first data point, year 2006 students 25 939" (if the axes were
| labeled "year" and "students", for example; they're not labeled
| in the example but it could still read out the positions of the
| points)
| derkades wrote:
| https://apache.github.io/echarts-handbook/en/best-practices/...
| potamic wrote:
| Is it even possible to make a chart accessible? I would have
| thought you would want to hide the chart and expose the raw
| table to screen readers.
| buovjaga wrote:
| I see there are unaddressed requests for improving
| accessibility:
|
| [Bug] ECharts claims to be accessible, but is not keyboard
| accessible https://github.com/apache/echarts/issues/18585
|
| [Feature] Support for accessibility of elements inside the
| chart (series, legend...)
| https://github.com/apache/echarts/issues/18256
| didip wrote:
| You are asking why Canvas? The answer is simple: Canvas is
| vastly better performing when given a large amount of
| datapoints. The difference is not even on the same plane.
| rogerrogerr wrote:
| Does anyone know of a way to print echarts to a PDF, without
| having a headless Chromium instance involved? Been fighting this
| at work.
| phonon wrote:
| https://www.blog.pythonlibrary.org/2018/04/12/adding-svg-fil...
| ?
| jaysen_apache wrote:
| after trying many charting, we settled on Apache Echart as well.
| its really flexible for lot of use-cases and customizable. if
| this doesnt work for you, the only option left is D3. Btw, we
| have not looked at many paid chart options like hicharts or
| other.
| MR4D wrote:
| The demo page is ridiculously long. I ran out of things to search
| for. Well done!
|
| https://echarts.apache.org/examples/en/index.html
| Jasonwuyc wrote:
| This is so cool!
| adeptima wrote:
| Happy eChart user. Added a tiny Reactjs wrapper on the top and
| ditched all D3 libraries. Never look back. Easy to inline and
| embed into slatejs based documents. Usable on mobile and
| responsive enough for my use cases.
| ggm wrote:
| longterm google charts user. This has attraction. Good eye candy
| feel, responsive.
|
| There are some specific things google charts do, like mark out
| kashmir and other disputed territories differently depending on
| your origin IP/AS so you don't fall foul of Indian law.
|
| There are some things google charts don't do, like re-center maps
| off the meridien they think is best. Scaling geo charts for the
| pacrim island nations is also very hard. No good choices there
| perhaps.
|
| Is there a migration guide?
| uwemaurer wrote:
| We use Echarts on our Bluesky analytics site
|
| https://bluefacts.app/profile/bsky.app
|
| Really great experience, we optimized the imports to reduce
| bundle size.
|
| For https://www.appbrain.com we also use it and had to optimize
| it even more.We render it server side and only return the SVG to
| the client.
|
| Server side rendering is a very powerful feature only very few
| chart libraries support.
| uwemaurer wrote:
| https://apache.github.io/echarts-handbook/en/how-to/cross-pl...
|
| also they have a very lightweight client library to add back
| interactive things like popups on hover when using server side
| rendering
| Brosper wrote:
| I never heard of them, hmm. Apache doing great work here.
| lysecret wrote:
| Never seen so much positivity related to a tool since SQLite
| kortilla wrote:
| Installing from random npm repos is so sketchy with supply chain
| attacks.
|
| Is 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.
| FlorianRappl wrote:
| Just recently (like 2 months ago) I had the task to evaluate
| proper OSS replacements for the main charting of a client. So
| far, they've used a paid solution - but there have been a couple
| of reasons why the wanted to migrate.
|
| Needless 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.
| pavish wrote:
| Glad to see Echarts getting the recognition it deserves. It is
| arguably the best open-source visualization library out there.
|
| Here are some points others haven't mentioned:
|
| (a) Uses canvas by default. Faster than any other library I've
| used.
|
| (b) Extremely flexible. Want to write your own widget on top of
| the graphs (eg., a customized tooltip). Possible!
|
| (c) Provides a lot of metadata. Want to get the position of a
| point in the rendered chart, to use in your code? Entirely
| possible!
|
| (d) Works really well when importing into legacy web apps. They
| even provide an option to get a customized build on their site.
|
| (e) Very good at handling streamed data. The animation is very
| smooth between data changes.
|
| I've been using it for almost 7 years now for various production
| and personal projects, and it's still my go-to library. Their
| docs have come a long way since then.
|
| They do have long standing bugs that get annoying, e.g, dealing
| with 0 when using log scales, provided there are workarounds for
| it. I haven't noticed any blocking bugs for most common usecases.
| pb060 wrote:
| > Glad to see Echarts getting the recognition it deserves.
|
| Why is it so rarely mentioned in chart libraries comparisons?
| Its not even listed on the Wikipedia page for JavaScript chart
| libraries. I discovered it by chance through Apache Superset.
| dev_l1x_be wrote:
| There is a super interesting port of ECharts to Rust:
| https://github.com/yuankunzhang/charming
| AndyPa32 wrote:
| The "Examples" page doesn't work for me. I don't get further than
| "Line Charts". (Firefox)
| pknerd wrote:
| wow!!
|
| Though it did not seem to have trading related charts like
| candlesticks and others
| remoroid wrote:
| Wow what a blast from the past. I used this library many years
| back when I think it was called Baidu E-Charts. Was a great
| library back then too. I'm amazed how good its gotten now.
| imcritic wrote:
| What a beautiful presentation!
| luffy-taro wrote:
| I wish it handled time zones properly, but everything else just
| works. The number of charts it supports is crazy. The second best
| was Apexcharts.
|
| https://echarts.apache.org/examples/en/index.html
| bArray wrote:
| I would love it if was possible to download the rendered chart,
| ideally headless. In peak traffic I would prefer to switch to a
| pre-rendered version, have the pre-rendered version available
| encase of an error (i.e. data retrieval), or for users not using
| JS.
|
| After the most minimal Google-foo, I see echarts-python [1] which
| has not been updated in 9 years. pyecharts [2] is looking pretty
| well maintained though.
|
| Years ago I tried my hand at writing a simple bar/line plotting
| filter for Pandoc that embeds itself into documents via an SVG in
| a URI [3]. If HN is permitting, you can past links like so [4]. I
| think writing a stand-alone tool to display the data you are
| interested in is a good idea for anybody.
|
| [1] https://github.com/yufeiminds/echarts-python
|
| [2]
| https://github.com/pyecharts/pyecharts/blob/master/README.en...
|
| [3] https://gitlab.com/danbarry16/pandoc-highlight-
| filter/-/blob...
|
| [4] (removed link as it was too long for the comments section)
| onychomys wrote:
| You can easily download a rendered chart by using the chart's
| getDataURL() function. Then just create a new element in your
| document and set that element's href to the return from
| getDataURL() and bob's your uncle.
| bArray wrote:
| I need to check that out, thank you!
| johntopia wrote:
| Nivo seems really nice. I recall that fey.com used it for their
| charts.
| teddyh wrote:
| No Debian package. Requested since 2022:
| <https://bugs.debian.org/1014408>
| didip wrote:
| Oh, good that it can choose between canvas or svg.
| https://apache.github.io/echarts-handbook/en/best-practices/...
|
| Canvas is the only game in town if you have huge amount of
| datapoints.
| egecant wrote:
| The `echarts4r` [1] R package lets you create ECharts charts
| directly in R and render them in graphical device, Shiny apps,
| Rmarkdown or Quarto documents.
|
| [1] https://echarts4r.john-coene.com/
| curl-up wrote:
| Over the last 7 years I've built 3 major products that needed
| charts. Every time I tested most of (at that time) popular
| solutions. All 3 times eCharts was by far the best option, across
| all criteria. Incredible library!
___________________________________________________________________
(page generated 2025-04-09 23:01 UTC)