Apache ECharts 6.1: A Declarative Charting Library That Puts the Option Object First

What ECharts Solves and Who It Serves

Apache ECharts targets a specific pain: turning tabular or hierarchical data into interactive charts without writing rendering code. It is a browser-side library written in TypeScript, and it builds on zrender, a lightweight canvas library. The README calls it 'free, powerful' and emphasizes that it is 'highly customizable.' That pitch is aimed at product teams who need line charts, bar charts, maps, and more, all inside a web page, and who want the result to be interactive out of the box. The target user is a front-end developer who can write a JavaScript object describing the chart, not a graphics specialist who wants to control every pixel. The core value is speed of construction: you define the data and the visual mapping, and ECharts handles the rest, including animations and tooltips.

The Declarative Option Object Is the Whole Interface

The central mechanism in ECharts is the option object. You do not call drawing functions in a loop. Instead, you pass a nested structure that describes the series, axes, and tooltip, and the library interprets it. The README links to an 'Option Manual' and an 'API' page, which together define the shape of that object. This is a fundamentally different approach from imperative libraries where you call methods to add data points. The trade-off is immediate: simple charts are astonishingly short, but complex charts can produce option objects that are hundreds of lines deep. The documentation exists to manage that complexity, but you will spend time learning the exact key names and accepted values. The payoff is consistency: once you know the schema, every chart type follows the same pattern.

Getting It Running: Install, Build, and Typecheck

The README gives three ways to obtain the library: download from the official website, install via npm with 'npm install echarts --save', or use the jsDelivr CDN. For developers who want to build from source, the instructions are explicit. You need Node.js, then run 'npm install' in the repository root. For development, 'npm run dev' rebuilds source code in watch mode and opens the './test' directory, where you can access '-cases.html' to see the full list of test cases. If you want to create a new test case, 'npm run mktest:help' explains how. TypeScript correctness is checked with 'npm run checktype'. Production files are generated with 'npm run release', which places them in the 'dist' directory. That build process is straightforward, but note that it assumes you are comfortable with a Node.js toolchain and a watch-mode workflow.

Rendering via Zrender: A Canvas Foundation

ECharts does not render directly to the DOM. It uses zrender, which the README describes as 'a whole new lightweight canvas library.' This means all drawing happens on a canvas element, not as SVG or HTML. The consequence is performance: canvas is generally faster for many elements, but it loses the DOM's accessibility and inspectability. You cannot right-click an individual bar and inspect it in the browser's element panel. The README does not mention SVG output or accessibility features, so you should assume canvas-only rendering. For dense data, such as a scatter plot with tens of thousands of points, canvas is often the right call. For a chart that must be screen-reader friendly, you may need to pair ECharts with an alternative or add your own ARIA layer. This is a genuine limitation, and the documentation does not soften it.

The Extension Ecosystem and Its Boundaries

The README lists several extensions that expand the core library. ECharts GL adds 3D plots, globe visualization, and WebGL acceleration. Others cover liquidfill gauges, word clouds, and a wrapper for Baidu Map SDK. There is also vue-echarts for Vue.js integration and echarts-stat for statistics. This ecosystem is a strength: you do not need to build a 3D chart from scratch. But it also creates a dependency question. Each extension is a separate project with its own release cycle. When ECharts core updates, an extension may lag behind. The README does not promise compatibility guarantees. If you rely on an extension, you must verify that it works with the ECharts version you are using. The extension list is not exhaustive, and the absence of a TypeScript declaration for a given extension could be an issue, though the core library is TypeScript-based.

What the Repository Does Not Tell You

The README is thin on several practical points. It does not state browser support minimums, though 'browser' is the stated environment. It does not describe the event system, though interactivity is a headline feature. It does not explain how to update an existing chart when data changes, a common task in dashboards. The documentation links point to external pages, so the README alone is not enough to evaluate the library's full API. This is a real gap for an engineer doing a quick evaluation. You will need to open the Option Manual and the API reference to answer basic questions like 'how do I change the data after the chart is rendered?' The README's brevity is fine for a mature project, but it means the repository alone does not give a complete picture. Plan to spend time on the official docs before making a decision.

Alternatives and the Difference in Approach

The most direct alternative is D3.js, which is not mentioned in the README but is the other dominant browser visualization tool. D3 is imperative and data-driven: you bind data to DOM elements and manipulate them directly. It gives you full control over the DOM, which means you can do SVG, canvas, or even HTML. ECharts is declarative and canvas-based, so you trade control for speed and convenience. If you need a custom chart type that does not exist in ECharts, D3 lets you build it from primitives. If you need a standard chart quickly, ECharts wins. Another alternative is a framework-specific wrapper like vue-echarts, which the README lists, but that still uses ECharts underneath. The real choice is between a high-level option-driven library and a low-level toolkit. Your data update frequency and the uniqueness of your visual requirements will decide which fits.

Maintenance, Licensing, and Upgrade Cost

The repository shows active maintenance. The latest release is 6.1.0, dated 2026-05-19, with release candidates in the same month. The project is part of the Apache Software Foundation, and the license is Apache-2.0. That is permissive for commercial use, and the README explicitly mentions 'commercial products.' The upgrade cost from a previous major version is not documented in the README. Given that 6.1.0 is recent, you should check the release notes for any breaking changes to the option schema. The project has a CI workflow, visible in the repository actions, which indicates automated testing. The build process includes a typecheck step, which helps catch errors during development. The extension ecosystem adds a separate maintenance burden, as each extension must be tracked individually. Overall, the project appears well maintained, but the documentation is the real cost center: you will spend time reading it.

Editorial conclusion

Adopt Apache ECharts if you need a broad set of interactive chart types with minimal code and you accept a declarative, option-driven model that can grow complex. Skip it if you want fine-grained control over every render frame or if your data updates are so frequent that a full re-render becomes a bottleneck. Before committing, verify that the chart types you need are in the core or available as an extension, and check the 6.1.0 release notes for any breaking changes to option keys. The project is actively maintained, with a 6.1.0 release dated 2026-05-19, so the upgrade path from 5.x is a concrete question to resolve first.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes