Charming: ECharts-based chart rendering for Rust

What Charming does that plain Rust plotting does not

Most Rust plotting crates draw pixels or vector paths themselves. Charming takes a different route: it builds a chart description in Rust, hands that description to Apache ECharts, and lets ECharts do the drawing. The README describes the goal as giving the Rust ecosystem "an intuitive and effective way to generate and visualize charts, using a declarative and user-friendly API." The audience is therefore Rust developers who already know what an ECharts chart looks like and want to produce one from Rust code rather than from JavaScript.

The payoff is breadth. Axis, legend, tooltip and series types come from ECharts, so the library does not have to reimplement each one. The cost is weight: rendering an image means running JavaScript, which the README confirms by saying the image renderer "makes use of an embed deno_core engine to execute the JavaScript code of Echarts." If your constraint is a tiny dependency footprint, this is the wrong shape of library.

Three renderers and the ssr/wasm split

Charming exposes three renderers, and the choice between them is the main architectural decision.

HtmlRenderer produces an HTML fragment and leaves the drawing to the browser. That is the lightest path and the one to use when the chart is going into a web page anyway.

ImageRenderer produces files. It is disabled by default and requires the ssr feature. Raster output (png, jpg and similar) sits behind a further flag, ssr-raster. The README lists a long set of formats, from SVG and PNG through TIFF, TGA, DDS, BMP, ICO, HDR, OPENEXR, FARBFELD, AVIF and QOI.

WasmRenderer runs inside a WebAssembly runtime, is disabled by default, and needs the wasm feature. The README states plainly that "the wasm feature and ssr feature are mutually exclusive," which is a real constraint on any crate that wants both server-side and client-side rendering in one build. You will be choosing per target, not per project.

Installing Charming and rendering a first chart

The README gives one install command. Adding the crate pulls in the default feature set; the image renderer needs the ssr feature turned on explicitly.

$ cargo add charming

The README's own first example draws a rose-type pie chart and saves it as SVG. It builds a Chart, attaches a Legend and a Pie series, then writes the file with ImageRenderer. The image renderer requires the ssr feature, which the README documents as the flag that enables it.

use charming::{
    component::Legend,
    element::ItemStyle,
    series::{Pie, PieRoseType},
    Chart, ImageRenderer
};

fn main() {
    let chart = Chart::new()
        .legend(Legend::new().top("bottom"))
        .series(
            Pie::new()
                .name("Nightingale Chart")
                .rose_type(PieRoseType::Radius)
                .radius(vec!["50", "150"])
                .center(vec!["50%", "50%"])
                .item_style(ItemStyle::new().border_radius(8))
                .data(vec![(40.0, "rose 1"), (38.0, "rose 2")]),
        );

    let mut renderer = ImageRenderer::new(1000, 800);
    renderer.save(&chart, "/tmp/nightingale.svg");
}

Running that program should leave an SVG file at /tmp/nightingale.svg. If you prefer a string in memory, the README shows renderer.render(&chart) returning an SVG string and render_format(ImageFormat::Png, &chart) returning PNG bytes. For a browser-side chart, HtmlRenderer::new("my charts", 1000, 800) followed by renderer.save(&chart, "/tmp/chart.html") writes a standalone HTML file.

The dependency and toolchain cost

The MSRV section is the least comfortable part of the README. It says the project provides no minimal supported Rust version and that it "is usually the latest stable release as the deno dependency upgrades their version very frequently." That is an honest statement, and it is also a maintenance liability: a crate that tracks the newest stable Rust cannot be pinned to an older toolchain, and the deno_core dependency is the reason. Teams on a fixed compiler version, or on a distribution toolchain, should treat this as a blocker rather than an inconvenience.

The same dependency explains build weight. Image rendering pulls in an embedded JavaScript engine, so the ssr feature is not a small addition to a compile graph. If you only ever need HTML fragments, the sensible move is to leave ssr and wasm off entirely.

The README also notes that custom themes are not supported yet, only the built-in set it illustrates (Default, Dark, Vintage, Westeros, Essos, Wonderland, Walden, Chalk, Infographic, Macarons, Roma, Shine, Purple Passion, Halloween), with "Future versions of Charming will support custom themes." If your brand requires a specific palette, you are limited to what ships today.

Where Charming is the wrong choice

If your charts must be produced without executing JavaScript, Charming's image path does not fit: the README is explicit that the image renderer executes ECharts code through an embedded deno_core engine. A pure-Rust rasterizer will not have that property.

If you need one binary that renders both on the server and in the browser, the mutual exclusion between ssr and wasm forces you to split builds or feature-gate code paths. That is workable but it is not free.

And if you are targeting a stable, long-lived toolchain, the no-MSRV policy is a direct conflict. The README does not document a rollback or compatibility matrix for older compilers, so there is nothing to fall back on when a new stable release breaks your build.

How Charming compares with plotters

plotters is the obvious alternative for Rust charting, and the difference is architectural rather than cosmetic. plotters draws directly to a backend (bitmap, SVG, or a GUI canvas) from Rust code, so it has no JavaScript engine in its dependency tree and no runtime to embed. Charming delegates drawing to ECharts and therefore inherits ECharts' chart types, themes and interaction model instead of reimplementing them.

The trade is straightforward. Choose plotters when you want a self-contained Rust drawing pipeline and are willing to define your own chart aesthetics. Choose Charming when you want ECharts output, are comfortable with the deno_core dependency, and can live with an MSRV that moves with stable Rust. Neither is a drop-in for the other; the APIs and the rendering model differ at the root.

Licence and upgrade expectations

The repository ships LICENSE-APACHE and LICENSE-MIT alongside a Cargo.toml that declares Apache-2.0, which is the usual dual-licence arrangement in the Rust ecosystem. Under Apache-2.0 you get an explicit patent grant and attribution requirements; the MIT option is the more permissive of the two. This is a description of what is in the repository, not legal advice, and the exact terms are in the licence files themselves.

On upgrades: there are no retrieved releases, and the README's MSRV note means the practical upgrade cadence is tied to whatever the deno dependency does. The repository was last pushed on 2026-09-27, so the code is current. A CHANGELOG.md exists at the top level, which is where release notes would appear; the README does not describe a deprecation or migration policy, so pinning a known-good revision is the only dependable strategy until you have read that changelog.

Editorial conclusion

Adopt Charming if you are writing Rust and want ECharts-quality output without shipping a JavaScript charting stack, and if you can accept a large dependency tree and a moving MSRV. Do not adopt it if you need a fixed minimum Rust version, a fully offline build on a locked-down machine, or custom themes today, since the README says custom themes are a future feature. Before committing, verify that your toolchain builds with the ssr feature, that ssr and wasm stay mutually exclusive in your Cargo configuration, and that the image format you need is actually supported by the ssr-raster flag.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. yuankunzhang/charming on GitHub