Lets-Plot for Kotlin, Python, and multiplatform graphics

Lets-Plot's multiplatform plotting problem

Lets-Plot addresses the need to construct statistical charts through explicit, composable visual components rather than selecting only from a fixed catalog of chart types. Its design follows the Grammar of Graphics described by Leland Wilkinson. The README quotes the core idea that independent components can be composed in different ways, allowing a graphic to be tailored to a problem rather than constrained by a predefined plot menu.

That model is relevant to Kotlin and Python developers who need graphics in several execution environments. The documented Kotlin use cases include Kotlin Notebook, Datalore, Jupyter with Kotlin Kernel, and other notebook environments supporting a Kotlin Kernel. Applications can also embed charts through Compose Multiplatform, JVM interfaces such as Swing and JavaFX, and Kotlin/JS.

The Python side is positioned as a bridge between R's ggplot2 approach and Python data visualization. This is not merely a Kotlin library with Python branding. The repository also contains `python-package`, `python-extension`, and `python-package-build`, while the primary language of the combined repository is Kotlin. Users should therefore decide which language and frontend they need before selecting a distribution or following setup instructions.

Lets-Plot is aimed at people who want a shared grammar for exploratory graphics, reporting, and embedded visualizations. Repository entries and documentation links indicate support for Python, notebooks, JVM applications, browser-oriented Kotlin/JS, Compose Multiplatform, raster output, vector-related components, live maps, and geospatial features. Those are broad application categories, but the README does not claim that every frontend has identical capabilities.

Repository modules behind chart construction and rendering

Based on the repository layout, Lets-Plot separates concerns across a substantial set of Gradle modules. `datamodel` appears to hold the data-facing layer, while `plot-base` and `plot-builder` form the central plotting foundation. Separate modules named `canvas`, `plot-raster`, and `plot-stem` indicate distinct rendering or presentation paths rather than one monolithic frontend.

The platform-oriented entries provide a clearer picture of the architecture. `platf-awt`, `platf-batik`, and `platf-imagick` point toward JVM and image-related integrations. `platf-w3c` and `wasmjs-package` indicate browser standards and WebAssembly-related packaging. The repository also includes `js-package` and `jvm-package`, plus `demo` directories for JVM, browser, WebAssembly, SVG, raster, export, and live-map scenarios.

Geospatial functionality has visible boundaries of its own. The `gis`, `livemap`, `plot-livemap`, and common livemap demo entries show that maps are a distinct part of the project rather than an incidental chart type. This separation can reduce the amount of unrelated machinery pulled into a given integration, although the README does not document dependency granularity or module stability.

The repository includes `visual-testing/` and `demo/` as well as generated documentation assets. Those entries suggest that visual output and examples are part of development, but the README does not describe the exact rendering pipeline, image comparison process, or compatibility policy. The defensible architectural conclusion is limited: Lets-Plot has distinct data, builder, platform, rendering, mapping, packaging, and demonstration areas. Claims about a specific internal algorithm would require source-level documentation that is not linked here.

Python notebooks, JVM, and Compose integration paths

Lets-Plot offers more than one way to place a chart into a working environment. Python users are directed to `lets-plot.org/python`, while Kotlin users are directed to the separate `JetBrains/lets-plot-kotlin` API project. That split matters because the umbrella README serves as an entry point rather than a complete language-specific setup guide.

For exploratory work, the documented notebook choices are Kotlin Notebook, Datalore, and Jupyter with Kotlin Kernel. The SciView plugin provides another route for interactive plotting in IntelliJ IDEA and PyCharm when Scientific mode is enabled. The README explicitly says Scientific mode is not available in community editions of JetBrains IDEs, so the plugin route is constrained to environments that provide the relevant commercial IDE feature.

For application embedding, the repository names Compose Multiplatform, JVM interfaces including Swing and JavaFX, and Kotlin/JS. The README links Kotlin application users to `JetBrains/lets-plot-kotlin` and Compose users to `JetBrains/lets-plot-compose`. This separation lets each frontend focus on its own integration while the shared project supplies plotting foundations.

The Python implementation is described as a bridge to the R ggplot2 model, which is useful for developers familiar with declarative statistical graphics. However, this README does not state that Lets-Plot offers complete ggplot2 compatibility. It gives no compatibility matrix, API parity claim, or list of unsupported R features. Such equivalence should not be assumed.

Locating installation instructions and beginning a first plot

The README does not provide an exact installation command, dependency coordinate, Python package name, Gradle configuration block, or first plotting code sample. It directs Python users to `lets-plot.org/python` and Kotlin users to the `JetBrains/lets-plot-kotlin` API documentation. Consequently, a command-based tutorial cannot be copied from the umbrella README without inventing details.

A first real setup should begin with the Python or Kotlin route. For Python, open the linked Python documentation and locate its package installation and plotting introduction. For Kotlin, open the API project linked from the README and select the guide matching the intended target: notebook, JVM, Kotlin/JS, or Compose Multiplatform. Compose developers should instead start with the separate `JetBrains/lets-plot-compose` project, because that repository is explicitly identified as the frontend guide.

After choosing the target, the reader needs four concrete outputs from that target documentation: the declared dependency, the import or call syntax for the first chart, the data shape accepted by the API, and the expected location or rendering mode for the result. The umbrella README confirms that notebooks and several application frontends are supported, but it does not establish the exact symbols or runtime setup.

This lack of commands is a documentation boundary, not evidence that installation is unsupported. The repository contains build files such as `build.gradle.kts`, `settings.gradle.kts`, package directories, and wrapper scripts, but those files describe development of the combined repository rather than an end-user installation. Users should not treat `./gradlew` as a consumer setup command without instructions from the relevant API project.

Maintenance, releases, and the MIT upgrade surface

The repository is not archived. Its last push was on 2026-07-02, and the release list includes `v4.11.0` dated 2026-06-30, followed by `v4.10.1` dated 2026-05-20. This release sequence confirms project changes during 2026, although the README does not describe a support window for each release or a formal long-term-support policy.

The upgrade cost cannot be reduced to a version number because consumers may use Python, Kotlin notebooks, JVM, Kotlin/JS, Compose Multiplatform, live maps, or rendering modules. Changes in one target may not apply equally to another. The repository also separates the Kotlin API and Compose frontend into other projects, so adopting this umbrella repository does not mean every component moves under a single user-facing release process.

Lets-Plot uses the MIT license, and the repository includes both `LICENSE` and `COPYRIGHT_NOTICE.md`. MIT licensing generally provides a permissive basis for use, modification, and distribution, but those files and the actual dependency licenses should be checked for a particular distribution. This review does not provide legal advice and does not replace examining the license texts.

There is another operational limit: the README does not document rollback, upgrade compatibility, migration automation, or a support policy for old releases. Those omissions matter for applications that pin versions in notebooks or build files. The concrete maintenance signal is the 2026 release activity, not a promise about migration effort.

Where Lets-Plot differs from fixed chart APIs

The most direct alternative approach is a conventional charting API built around fixed functions for bars, lines, scatter plots, and other predefined chart types. Such an API may be easier for a narrow application that only needs one chart and accepts the library's default visual structure. Lets-Plot instead starts from composable Grammar of Graphics components, so the same basic plot can be modified through explicit mappings, scales, coordinates, and related layers.

A second alternative is to call ggplot2 directly from R. The README positions Lets-Plot's Python offering as a bridge between R's ggplot2 and Python visualization, which means it is intended to carry that declarative design into Python rather than merely wrap R runtime execution. The README does not specify the bridge mechanism, so it would be inaccurate to claim that it embeds R or reproduces ggplot2 wholesale.

Lets-Plot is the wrong tool when a team wants one documented command and one identical chart API across every listed frontend without reading platform-specific guides. It is also a poor fit for a project whose only requirement is a simple fixed chart and whose maintenance policy favors the narrowest possible dependency. Its strongest fit is a team already invested in Kotlin, Python notebooks, or multiplatform applications and willing to evaluate the target-specific API documentation before committing.

Editorial conclusion

Lets-Plot is a sensible choice for Kotlin or Python teams that want a Grammar of Graphics API across notebooks, JVM, Kotlin/JS, or Compose Multiplatform. It is less suitable when users require an offline installation command or a documented API example from the umbrella README. Before adoption, verify that the target-specific documentation provides the exact dependencies, platform support, and first chart example needed by the intended application.

Frequently asked questions

Official sources

1. JetBrains/lets-plot on GitHub
2. License: MIT
3. Project website
4. README
5. Releases