Which IPC transport should a Tauri 2 app standardize on for paginating a large dataset to the webview?

Short answer

Standardize on a single #[tauri::command] per page, invoked with a cursor or offset, returning a bounded slice. At ~100 rows per page this is almost always fast enough for instant scrolling, and it keeps your data layer simple: one request, one response, natural error handling, and trivial cancellation (just stop invoking). Reserve Channel for the cases where measurement — not anticipation — shows a page payload large enough to stall the webview's JSON parsing.

Why a command wins at page size

The latency you fear is dominated by two things: serializing the payload in Rust and parsing the JSON string on the webview's main thread. For a page of 100 typical rows, the serialized JSON is usually in the low tens of kilobytes, and both serialization and parsing complete in single-digit milliseconds on modern hardware — well inside a 16 ms frame budget. Chunking that payload across a Channel adds coordination complexity without removing work you can actually perceive.

A rule of thumb worth treating as a hypothesis, not a law: if a page's serialized size stays under roughly 50 KB and your measured invoke round-trip is comfortably under one frame, a command is sufficient. Past that point — wide rows, embedded text blobs, denormalized joins — the single monolithic JSON.parse on the JS thread becomes the long task that drops frames, and incremental delivery starts paying for itself.

What Channel actually buys you

Channel is an async, ordered stream from Rust to the webview. Compared to events it gives you two things that matter for incremental rendering:

• Ordered iteration as a first-class API. You consume chunks sequentially in one logical stream tied to one request, rather than correlating fire-and-forget event emissions yourself.
• Natural pacing. Because the webview pulls chunks through an iterator-style interface, a busy renderer slows consumption instead of being buried under a burst of queued events. Events have no such mechanism: if the listener is blocked, messages pile up, and you have no built-in signal to slow the emitter.

That makes Channel the right tool for unbounded or very large result sets — "stream all matches" rather than "fetch page N" — where you render rows as they arrive. The costs are real: you must drive the stream on both sides, handle early termination (user scrolls away, filters change), and clean up the channel when the webview navigates or is destroyed, or you leak the Rust-side sender.

Is there a documented threshold?

No. Tauri 2's documentation presents commands, events, and Channel without prescribing a payload cutoff for bulk reads. Any specific number — including the ~50 KB guideline above — is a heuristic to validate against your own schema and hardware, not a contract from the framework. Treat it as a starting point for benchmarking, and re-check it if you upgrade Tauri or change webview runtimes.

What to measure before deciding

1. Payload size: JSON.stringify(page).length in the webview for your largest realistic page.
2. Round-trip latency: wrap the invoke in performance.now() timestamps; separately measure time from response received to rows rendered.
3. Main-thread impact: scroll a virtualized list while profiling in DevTools and look for long tasks (>16 ms) that line up with IPC responses. If parse-and-render is the long task, that's your signal to chunk.

If those numbers stay healthy at your target page size, ship the command-based design and keep Channel in your back pocket for the "export everything" or live-tail features where streaming is genuinely the right shape.