arxiv: 2605.14118 · v1 · submitted 2026-05-13 · 💻 cs.HC

Recognition: no theorem link

Pluot: Towards 'write once, run everywhere' visualization software

Mark S. Keller , Nils Gehlenborg

Authors on Pith no claims yet

Pith reviewed 2026-05-15 01:41 UTC · model grok-4.3

classification 💻 cs.HC

keywords visualizationRustlanguage bindingscross-environment renderinginteractive graphicsvector outputwrite once run everywhere

0 comments

The pith

A visualization rendering function written once in Rust can execute from Python or JavaScript and produce both interactive displays and vector graphics output.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents Pluot as an architecture that lets developers write visualization rendering logic a single time in Rust. Bindings generated from that Rust code then allow the same function to run in other languages such as Python and JavaScript. The system supports output in either bitmap form for interactivity or vector form for publication-quality figures. This setup is intended to remove the need to maintain separate codebases for static versus interactive or desktop versus web environments.

Core claim

With Pluot, a visualization developer implements a given visualization rendering function once using the Rust programming language, after which bindings to the Rust program are generated to enable reproducible execution of the rendering function from other languages such as Python or JavaScript while supporting both bitmap and vector graphics formats.

What carries the argument

The Pluot architecture that implements the core rendering function in Rust and generates language bindings for execution across environments.

If this is right

Developers maintain only one source implementation instead of separate versions for each target language or environment.
The same rendering code can drive both real-time interactive applications and static publication figures.
Reproducibility improves because the core logic remains identical across language bindings.
Visualization software can move more easily between desktop, web, and scripting workflows without rewriting rendering routines.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The approach could reduce maintenance effort when updating visualizations that must appear in multiple publication formats and interactive tools.
If binding overhead remains low, similar single-source methods might apply to other performance-sensitive domains such as scientific simulation output.
Adoption would depend on the ease of generating and distributing the language bindings for common research environments.

Load-bearing premise

Bindings from the Rust rendering code to other languages can preserve both interactive performance and output fidelity without major compatibility or overhead problems.

What would settle it

A side-by-side test where the same visualization rendered through a Pluot-generated JavaScript binding shows noticeably lower frame rate or visible distortion in vector output compared with a native Rust implementation.

Figures

Figures reproduced from arXiv: 2605.14118 by Mark S. Keller, Nils Gehlenborg.

**Figure 1.** Figure 1: Pluot architecture. a) The status quo. Visualization developers often use different toolkits depending on whether a plot [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗

**Figure 2.** Figure 2: Examples of graphics created with Pluot. a) Scatterplot [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

read the original abstract

Tools used for implementing visualization software systems can generally be divided into camps such as static versus interactive and desktop versus web-based. We contribute Pluot, an architecture that bridges these divides, enabling a single software implementation of a visualization to be used regardless of the target level of interactivity or computing environment. With Pluot, a visualization developer implements a given visualization rendering function once, using the Rust programming language. Then, bindings to the Rust program can be generated to enable reproducible execution of the rendering function from other languages, such as Python or JavaScript. Pluot can render visualizations to bitmap or vector graphics format, bridging gaps between interactive performance and publication-quality figure creation. The software is available at https://pluot.dev.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

Pluot gives a Rust-based way to write a viz renderer once and bind it to Python or JS with bitmap/vector output, but the paper provides no data on binding overhead.

read the letter

Pluot tries to cut down on duplicated visualization code by letting a developer write the core rendering function once in Rust, then auto-generate bindings for languages like Python and JavaScript. The same implementation can produce both interactive bitmap output and vector graphics for publication figures. That directly targets the static-versus-interactive and desktop-versus-web splits that force repeated work in the field. The software is already up at pluot.dev, which is useful for anyone who wants to inspect or try the bindings themselves. The architecture description is clear on how Rust serves as the single source of truth for reproducibility across environments. This is the part that feels like a concrete step rather than another abstract proposal. The main shortcoming is the missing evaluation. The paper lays out the goals and the binding mechanism but shows no numbers on frame rates, latency, or output fidelity when the Rust code runs through the generated bindings versus natively. Without those comparisons, it is hard to judge whether FFI or WASM costs stay low enough for real interactive use or whether vector results stay bit-identical. That assumption sits at the center of the claim and is left untested in the reported work. The paper is aimed at visualization tool builders who already maintain code across multiple platforms and want to reduce that maintenance load. A developer working on a new rendering library could borrow the binding pattern even if they do not adopt the full system. It deserves peer review because the problem is real, the software exists, and the architecture is described in enough detail to evaluate. Reviewers would likely ask for the missing benchmarks, but the core idea is worth that discussion.

Referee Report

2 major / 2 minor

Summary. The paper presents Pluot, an architecture allowing visualization developers to implement a rendering function once in Rust, after which bindings are generated to enable reproducible execution from other languages such as Python and JavaScript. The system supports rendering to both bitmap (for interactivity) and vector graphics (for publication quality), aiming to bridge static versus interactive and desktop versus web-based visualization tools. Software is available at https://pluot.dev.

Significance. If the performance and fidelity claims hold, Pluot would offer a practical path toward write-once-run-everywhere visualization code, reducing duplication across environments and improving reproducibility of interactive and static figures alike.

major comments (2)

[Evaluation / Results] The central claim that generated bindings preserve interactive frame rates and vector fidelity without significant overhead is load-bearing, yet the manuscript provides no quantitative comparison of native Rust execution versus bound versions (e.g., frame-rate measurements or FFI/WASM overhead). This evaluation gap must be addressed with concrete benchmarks before the architecture can be assessed as delivering on its performance promises.
[Architecture / Implementation] The description of the binding-generation process (how Rust code is exposed to Python/JS while maintaining vector-output equivalence) is presented at a high level only; without details on the specific mechanisms or any compatibility edge cases tested, it is difficult to evaluate the reproducibility claim.

minor comments (2)

[Abstract] The abstract states the goals clearly but could include one sentence on the concrete binding technology (e.g., wasm-bindgen, cxx, or PyO3) to orient readers immediately.
[Figures] Figure captions and any accompanying diagrams should explicitly label which components run natively in Rust versus which run through the generated bindings.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript describing Pluot. We address the major comments point by point below and will revise the paper to strengthen the evaluation and implementation details.

read point-by-point responses

Referee: [Evaluation / Results] The central claim that generated bindings preserve interactive frame rates and vector fidelity without significant overhead is load-bearing, yet the manuscript provides no quantitative comparison of native Rust execution versus bound versions (e.g., frame-rate measurements or FFI/WASM overhead). This evaluation gap must be addressed with concrete benchmarks before the architecture can be assessed as delivering on its performance promises.

Authors: We agree that quantitative benchmarks are required to substantiate the performance claims. In the revised manuscript we will add a new evaluation section containing frame-rate measurements (in FPS) for native Rust, Python bindings, and JavaScript/WASM bindings on representative visualization workloads. We will also report vector-output fidelity metrics (e.g., file-size equivalence and pixel-level rendering accuracy) and quantify FFI/WASM overhead. revision: yes
Referee: [Architecture / Implementation] The description of the binding-generation process (how Rust code is exposed to Python/JS while maintaining vector-output equivalence) is presented at a high level only; without details on the specific mechanisms or any compatibility edge cases tested, it is difficult to evaluate the reproducibility claim.

Authors: We will expand the architecture section with concrete details on the binding-generation pipeline, including the specific Rust crates and code-generation steps used to produce Python and JavaScript interfaces while preserving vector-output equivalence. We will also add a subsection documenting the compatibility edge cases we tested (e.g., complex data-structure marshalling, error propagation, and floating-point consistency) together with the observed results. revision: yes

Circularity Check

0 steps flagged

No circularity; architecture presented as independent system contribution

full rationale

The paper describes a new software architecture (Pluot) for implementing visualization rendering functions once in Rust and generating language bindings. No equations, fitted parameters, predictions, or self-citations appear in the provided text as load-bearing elements of any derivation. The central claim is the existence and design of the system itself, supported by external software availability at pluot.dev rather than any reduction to prior inputs by construction. This is a standard systems contribution with no detectable self-definitional, fitted-input, or uniqueness-imported circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the domain assumption that Rust can serve as a portable core for visualization rendering with reliable bindings to other languages and dual output formats.

axioms (1)

domain assumption Rust can be used to implement portable rendering functions with bindings to other languages.
The system relies on the feasibility of Rust bindings and rendering capabilities.

pith-pipeline@v0.9.0 · 5413 in / 1119 out tokens · 36953 ms · 2026-05-15T01:41:03.128003+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

43 extracted references · 43 canonical work pages

[1]

Last accessed 2026-04-

SciChart.https://www.scichart.com/. Last accessed 2026-04-

work page 2026
[2]

Last ac- cessed 2025-08-29

React.https://github.com/facebook/react, 2025. Last ac- cessed 2025-08-29. 3

work page 2025
[3]

Beaufort

F. Beaufort. WebGPU is now supported in major browsers.https: //web.dev/blog/webgpu-supported-major-browsers, 2025. Last accessed 2026-04-09. 4

work page 2025
[4]

M. Bitar. Rust and Julia for Scientific Computing.Computing in Science & Engineering, 26(1):72–76, Jan. 2024. doi: 10.1109/MCSE .2024.3369988 3

work page doi:10.1109/mcse 2024
[5]

L. Deakin. zarrs: A High-Performance Rust Library for the Zarr Array Storage Format.https://github.com/zarrs/zarrs, 2025. Last accessed 2026-02-02. 3

work page 2025
[6]

I. F. Diks, M. Flotho, and A. Keller. SingleRust: A High-Performance Toolkit for Single-Cell Data Analysis at Scale, Sept. 2025. doi: 10. 1101/2025.08.04.668429 3

work page 2025
[7]

Gillmann, T

C. Gillmann, T. Itoh, M. Krone, A. Lex, and G. Reina. The Moving Target of Visualization Software – Closing the Gap between Research and Application.Shonan Meeting, (193), 2024. 2

work page 2024
[8]

SwiftShader.https://github.com/google/ swiftshader, 2026

Google. SwiftShader.https://github.com/google/ swiftshader, 2026. Last accessed 2026-04-21. 4

work page 2026
[9]

Heer and D

J. Heer and D. Moritz. Mosaic: An Architecture for Scalable & Inter- operable Data Views.IEEE Transactions on Visualization and Com- puter Graphics, pp. 1–11, 2023. doi: 10.1109/TVCG.2023.3327189 2

work page doi:10.1109/tvcg.2023.3327189 2023
[10]

Herzberger, M

L. Herzberger, M. Hadwiger, R. Kr ¨uger, P. Sorger, H. Pfister, E. Gr ¨oller, and J. Beyer. Residency Octree: A Hybrid Approach for Scalable Web-Based Multi-V olume Rendering.IEEE Transactions on Visualization and Computer Graphics, pp. 1–11, 2023. doi: 10.1109/ TVCG.2023.3327193 2

work page arXiv 2023
[11]

J. D. Huey and N. Abdennur. Bigtools: A high-performance BigWig and BigBed library in Rust.Bioinformatics, 40(6):btae350, June 2024. doi: 10.1093/bioinformatics/btae350 3

work page doi:10.1093/bioinformatics/btae350 2024
[12]

R. Hunt. Why is WebAssembly a second-class language on the web?https://hacks.mozilla.org/2026/02/ making-webassembly-a-first-class-language-on-the-web/,

work page 2026
[13]

Last accessed 2026-04-09. 4

work page 2026
[14]

M. Keller. Anyhtmlwidget.https://github.com/keller-mark/ anyhtmlwidget, 2025. Last accessed 2025-09-01. 2

work page 2025
[15]

M. S. Keller, I. Gold, C. McCallum, T. Manz, P. V . Kharchenko, and N. Gehlenborg. Vitessce: Integrative visualization of multimodal and spatially resolved single-cell data.Nature Methods, pp. 1–5, Sept

work page
[16]

doi: 10.1038/s41592-024-02436-x 1

work page doi:10.1038/s41592-024-02436-x
[17]

M. S. Keller, T. Manz, and N. Gehlenborg. Use-Coordination: Model, Grammar, and Library for Implementation of Coordinated Multiple Views. In2024 IEEE Visualization and Visual Analytics (VIS), pp. 166–170, Oct. 2024. doi: 10.1109/VIS55277.2024.00041 2

work page doi:10.1109/vis55277.2024.00041 2024
[18]

A. Kohn, D. Moritz, M. Raasveldt, H. M ¨uhleisen, and T. Neumann. DuckDB-wasm: Fast analytical processing for the web.Proceed- ings of the VLDB Endowment, 15(12):3574–3577, Aug. 2022. doi: 10.14778/3554821.3554847 2

work page doi:10.14778/3554821.3554847 2022
[19]

K ¨oster

J. K ¨oster. Rust-Bio: A fast and safe bioinformatics library.Bioin- formatics, 32(3):444–446, Feb. 2016. doi: 10.1093/bioinformatics/ btv573 3

work page doi:10.1093/bioinformatics/ 2016
[20]

Lekschas

F. Lekschas. DOM 2D Camera.https://github.com/ flekschas/dom-2d-camera, 2024. Last accessed 2026-04-17. 3

work page 2024
[21]

Lekschas and T

F. Lekschas and T. Manz. Jupyter Scatter: Interactive Exploration of Large-Scale Datasets.Journal of Open Source Software, 9(101):7059, Sept. 2024. doi: 10.21105/joss.07059 2

work page doi:10.21105/joss.07059 2024
[22]

A. T. L. Lun and J. Kancherla. Powering single-cell analyses in the browser with webassembly.Journal of Open Source Software, 8(89):5603, 2023. doi: 10.21105/joss.05603 2

work page doi:10.21105/joss.05603 2023
[23]

S. L’Yi, M. S. Keller, A. Dandawate, L. Taing, C.-H. Chen, M. Brown, C. A. Meyer, and N. Gehlenborg. Cistrome Explorer: An interactive visual analysis tool for large-scale epigenomic data.Bioinformatics, 39(2), Feb. 2023. doi: 10.1093/bioinformatics/btad018 1

work page doi:10.1093/bioinformatics/btad018 2023
[24]

S. L’Yi, Q. Wang, F. Lekschas, and N. Gehlenborg. Gosling: A Grammar-based Toolkit for Scalable and Interactive Genomics Data Visualization.IEEE transactions on visualization and com- puter graphics, 28(1):140–150, Jan. 2022. doi: 10.1109/TVCG.2021. 3114876 3

work page doi:10.1109/tvcg.2021 2022
[25]

M. Lysenko. 3d-view-controls.https://github.com/ mikolalysenko/3d-view-controls, 2018. Last accessed 2026-04-17. 3

work page 2018
[26]

T. Manz, N. Abdennur, and N. Gehlenborg. Anywidget: Reusable widgets for interactive analysis and visualization in computational notebooks.Journal of Open Source Software, 9(102):6939, Oct. 2024. doi: 10.21105/joss.06939 2

work page doi:10.21105/joss.06939 2024
[27]

T. Manz, I. Gold, N. H. Patterson, C. McCallum, M. S. Keller, B. W. Herr, K. B¨orner, J. M. Spraggins, and N. Gehlenborg. Viv: Multiscale visualization of high-resolution multiplexed bioimaging data on the web.Nature Methods, pp. 1–2, May 2022. doi: 10.1038/s41592-022 -01482-7 1, 3

work page doi:10.1038/s41592-022 2022
[28]

T. Manz, S. L’Yi, and N. Gehlenborg. Gos: A declarative library for interactive genomics visualization in Python.Bioinformatics, 39(1), Jan. 2023. doi: 10.1093/bioinformatics/btad050 3

work page doi:10.1093/bioinformatics/btad050 2023
[29]

McCormick and P

M. McCormick and P. Elliott. ITK-Wasm: Universal spatial analy- sis and visualization. InPython in Science Conference, pp. 256–279. Tacoma, Washington, July 2024. doi: 10.25080/TCFJ5130 2

work page doi:10.25080/tcfj5130 2024
[30]

J. Mease. Introducing VlConvert.https://medium.com/ @jonmmease/introducing-vlconvert-c763f0076e89, 2022. Last accessed 2026-04-09. 2

work page 2022
[31]

Moore, C

J. Moore, C. Allan, S. Besson, J.-M. Burel, E. Diel, D. Gault, K. Ko- zlowski, D. Lindner, M. Linkert, T. Manz, W. Moore, C. Pape, C. Tis- cher, and J. R. Swedlow. OME-NGFF: A next-generation file for- mat for expanding bioimaging data-access strategies.Nature Methods, 18(12):1496–1498, Dec. 2021. doi: 10.1038/s41592-021-01326-w 4

work page doi:10.1038/s41592-021-01326-w 2021
[32]

Pechuk and J

R. Pechuk and J. Heer. Publish-time optimizations for web-based vi- sualizations. InProc. IEEE VIS Short Papers, 2025. 4

work page 2025
[33]

J. M. Perkel. Why scientists are turning to Rust.Nature, 588(7836):185–186, Dec. 2020. doi: 10.1038/d41586-020-03382-2 3

work page doi:10.1038/d41586-020-03382-2 2020
[34]

Satyanarayan, D

A. Satyanarayan, D. Moritz, K. Wongsuphasawat, and J. Heer. Vega- Lite: A grammar of interactive graphics.IEEE Trans. Vis. Comput. Graph., 23(1):341–350, Jan. 2017. 2, 3

work page 2017
[35]

Matthew Weinberg

E. Schneider, B. Robertson, A. Kuhn, C. Lux, and M. Nienhaus. NVIDIA IndeX accelerated computing for visualizing Cholla’s galac- tic winds.Parallel Computing, 107:102809, Oct. 2021. doi: 10.1016/j .parco.2021.102809 2

work page doi:10.1016/j 2021
[36]

2025 Developer Survey.https: //survey.stackoverflow.co/2025/technology/ #admired-and-desired, 2025

StackOverflow. 2025 Developer Survey.https: //survey.stackoverflow.co/2025/technology/ #admired-and-desired, 2025. Last accessed 2026-04-21. 4

work page 2025
[37]

G. W. Stagg, H. Lionel, and Others. webR: The statistical language R compiled to WebAssembly via Emscripten, Nov. 2023. 2

work page 2023
[38]

pyodide/pyodide, Aug

The Pyodide development team. pyodide/pyodide, Aug. 2021. doi: 10 .5281/zenodo.5156931 2

work page 2021
[39]

Usher and V

W. Usher and V . Pascucci. Interactive Visualization of Terascale Data in the Browser: Fact or Fiction? In2020 IEEE 10th Symposium on Large Data Analysis and Visualization (LDA V), pp. 27–36, Oct. 2020. doi: 10.1109/LDA V51489.2020.00010 2

work page doi:10.1109/lda 2020
[40]

Altair: Interactive Statistical Visualizations for Python

J. VanderPlas, B. Granger, J. Heer, D. Moritz, K. Wongsuphasawat, A. Satyanarayan, E. Lees, I. Timofeev, B. Welsh, and S. Sievert. Al- tair: Interactive Statistical Visualizations for Python.Journal of Open Source Software, 3(32):1057, Dec. 2018. doi: 10.21105/joss.01057 3

work page doi:10.21105/joss.01057 2018
[41]

Vieth, T

A. Vieth, T. Kroes, and J. Thijssen. ManiVault: A Flexible and Exten- sible Visual Analytics Framework for High-Dimensional Data. 2023. 2

work page 2023
[42]

Wiewi ´orka, P

M. Wiewi ´orka, P. Khamutou, M. Zbysi ´nski, and T. Gambin. Polars- bio—fast, scalable, and out-of-core operations on large genomic in- terval datasets.Bioinformatics, 41(12):btaf640, Dec. 2025. doi: 10. 1093/bioinformatics/btaf640 3

work page 2025
[43]

Williams, J

E. Williams, J. Moore, S. W. Li, G. Rustici, A. Tarkowska, A. Ches- sel, S. Leo, B. Antal, R. K. Ferguson, U. Sarkans, A. Brazma, R. E. Carazo Salas, and J. R. Swedlow. Image Data Resource: A bioimage data integration and publication platform.Nature Methods, 14(8):775–781, Aug. 2017. doi: 10.1038/nmeth.4326 4

work page doi:10.1038/nmeth.4326 2017