Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Why Is It Designed This Way?

Design rationaleOne model, many boundariesRevision 1b998fc

Why archetypes made of components?

Points3D is an ergonomic semantic bundle, but positions, colors, labels, and radii remain independently queryable component columns. New optional components can extend a visualization without replacing an opaque point-cloud payload.

Why use Arrow everywhere?

Arrow provides columnar arrays shared by Rust, Python, C++, transport, storage, and analytical query code. A single representation avoids repeatedly translating every value into row objects at subsystem boundaries.

Why micro-batch synchronous log calls?

The user should be able to log from ordinary code without making their whole application async. A dedicated batching pipeline coalesces tiny rows into efficient chunks, while byte budgets stop that convenience from becoming an unbounded memory queue.

Why identify data by entity path, component, timeline, and row ID?

Multimodal streams arrive at different rates and may be updated independently. These axes let a viewer ask “what was the latest color at this time?” while maintaining deterministic ordering and component-level history.

Why an immediate-mode viewer?

Each frame derives visible state from the current blueprint, time, and stored data. This avoids a large web of mutation callbacks whose cached UI state can drift from the selected time. Memoization and the renderer retain expensive work beneath that conceptually fresh frame.

Why separate native and WebAssembly scheduling?

Native builds can use threads, blocking channels, Tokio, and direct files. Browser builds generally own a single local event loop and browser APIs. cfg-selected capability wrappers preserve the higher-level pipeline without claiming both platforms have identical blocking or Send behavior.