Taffy: a Rust layout engine for Flexbox, CSS Grid and Block

What problem Taffy solves, and who it is for

Browsers get layout for free. A Rust renderer, game engine or terminal UI does not. Someone has to turn a tree of styled boxes into pixel rectangles, and reimplementing Flexbox and CSS Grid by hand is a large, specification-driven job. Taffy is that job, packaged as a crate. The README describes it as "a flexible, high-performance, cross-platform UI layout library written in Rust" and states that it implements the CSS Block, Flexbox and CSS Grid algorithms, with other paradigms planned and tracked in a roadmap issue.

The intended consumer is not an application developer. The README says the crate "is designed to be used as a dependency for other UI and GUI libraries" and names the projects it currently powers: Servo, Blitz, Bevy, Takumi, iocraft, Slint, and the Lapce and Zed editors through their respective UI frameworks. That list is the clearest statement of scope. If you are writing an app in Bevy or Slint, you consume Taffy indirectly. If you are writing the layer that Bevy or Slint sits on, Taffy is aimed at you.

How Taffy represents a layout tree and computes it

Taffy does not own your scene graph. You build a tree of nodes yourself, either using the built-in TaffyTree or by implementing Taffy's tree traits over your own storage. The repository ships examples for both paths: examples/custom_tree_vec.rs, examples/custom_tree_owned_partial.rs and examples/custom_tree_owned_unsafe.rs show the custom-storage variants, which is a sign the authors expect engines to keep their own arenas rather than copy nodes in.

Each node carries a Style struct. You set fields such as size, flex_grow and flex_direction, then call compute_layout on the root with an available space. Taffy walks the tree, runs the algorithm selected by the style, and writes results back. You read them with tree.layout(node_id). The README's own example asserts that a body node with height: auto and flex_grow: 1.0 resolves to 500.0 inside an 800 by 600 column with a fixed 100-pixel header. That is the whole contract: styles in, rectangles out.

Two design details matter in practice. First, the crate has no text layout. The benchmark notes in the README say popular websites run 3,000 to 10,000 nodes "although they also require text layout, which neither yoga nor taffy implement." You supply measured text as a leaf size. Second, the algorithms are feature-gated. Cargo.toml lists block_layout, float_layout, flexbox, flexbox_balance, grid, calc, content_size and detailed_layout_info among the defaults, so a build can drop grid or block entirely if you only need Flexbox.

Installing Taffy and running a first layout

Taffy is published on crates.io, and the README's usage section is a Rust snippet rather than a CLI walkthrough. Add the dependency, then create a tree. The version in the repository's Cargo.toml is 0.14.0, and the crate declares rust-version = "1.71", so a toolchain at or above that is required.

cargo add taffy

The README example builds three nodes and asserts the computed geometry. In compact form, the root is a column 800 wide and 600 tall, the header is a fixed 100 tall leaf, and the body grows to fill the remainder.

use taffy::prelude::*;

let mut tree: TaffyTree<()> = TaffyTree::new();
let header = tree.new_leaf(Style {
    size: Size { width: length(800.0), height: length(100.0) },
    ..Default::default()
})?;
let body = tree.new_leaf(Style {
    size: Size { width: length(800.0), height: auto() },
    flex_grow: 1.0,
    ..Default::default()
})?;
let root = tree.new_with_children(Style {
    flex_direction: FlexDirection::Column,
    size: Size { width: length(800.0), height: length(600.0) },
    ..Default::default()
}, &[header, body])?;
tree.compute_layout(root, Size::MAX_CONTENT)?;

After compute_layout returns, tree.layout(body) reports a height of 500.0 even though that value was never set. If you want a worked example closer to a real screen, examples/grid_holy_grail.rs in the repository lays out the classic holy grail page with CSS Grid, and examples/measure.rs covers the callback you need when a leaf's size depends on text.

Where Taffy stops: text, painting and the benchmark caveat

Taffy computes boxes. It does not measure glyphs, rasterize anything, handle scrolling, or know about events. Every one of those is your responsibility, and text is the one that bites first, because a paragraph's height is an input to layout, not an output. The measure example exists precisely because you must hand Taffy a closure that returns a size for text leaves.

The README's benchmark table deserves a careful read rather than a skim. It is run on a 2021 MacBook Pro with an M1 Pro using criterion, measures layout computation only and not tree creation, and compares against Yoga through the yoga-rs bindings. The results are not a clean sweep. Taffy is faster on the wide 1,000-node case (505.99 µs against 737.77 µs) and on the deep trees, but slower on wide 10,000 and 100,000-node trees, where Yoga reports 7.1007 ms and 135.78 ms against Taffy's 8.3395 ms and 247.42 ms. Anyone choosing Taffy purely on the strength of the word "high-performance" in the description should look at that table first. The advantage is real on deep and super-deep trees; on very wide flat trees it is not there.

Taffy compared with Yoga, and with writing your own layout

Yoga is the obvious comparison, and the README makes it directly. The difference is scope. Yoga implements Flexbox and is the layout engine behind React Native. Taffy implements Block, Flexbox and CSS Grid, and the README frames that breadth as the point: it is a cross-team project meant to serve browsers, game engines and GUI toolkits at once. If your interface is Flexbox-only and you are already in the Yoga ecosystem, switching buys you Grid and costs you a migration.

The other alternative is not a library at all. A renderer with a narrow, fixed set of screens can hard-code its geometry and skip the tree, the style struct and the compute pass entirely. That is a legitimate choice for a tool with three panels and no user-authored layout. Taffy becomes the right call when layout is data: when styles come from somewhere you do not control, when the tree depth varies at runtime, or when you want CSS semantics that web developers already know. The README leans on this directly, pointing readers at MDN property pages and at Flexbox Froggy and CSS Grid Garden for learning, on the grounds that Taffy implements the specifications faithfully enough that web documentation transfers.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-21. Releases have been frequent: v0.14.0 on 2026-08-24, v0.13.0 on 2026-08-08, and v0.12.2 on 2026-07-19. That cadence matters because the crate is still pre-1.0, which means minor version bumps are the breaking-change boundary. A 0.13 to 0.14 upgrade is not a patch, and the CHANGELOG.md at the repository root is where you check what moved before you bump.

Licensing is straightforward. Cargo.toml declares license = "MIT", and the repository carries a LICENSE file at the top level. MIT is permissive, so the usual obligations apply: keep the copyright notice and the licence text with any distribution. That is a description of what the file says, not legal advice, and if you ship Taffy inside a commercial product you should have your own counsel confirm the notice requirements.

Upgrade cost is mostly the pre-1.0 churn plus feature flags. If you build with default features you carry the CSS parser dependency (cssparser is optional and only pulled in when the relevant feature is on) and the full algorithm set. Trimming features reduces what can break under you. The justfile shows the project's own checks: cargo fmt --all for formatting and cargo +nightly clippy --workspace for lints, both of which are reasonable to mirror in a downstream CI job that vendors or patches the crate.

Editorial conclusion

Adopt Taffy if you are building a Rust UI framework, renderer or game engine and need CSS layout as a dependency rather than as a browser feature. Do not adopt it if you need text measurement, painting, or a working Python or WASM binding today, since those bindings are marked WIP. Before committing, check that your target platform meets the crate's rust-version of 1.71, and read the docs.rs feature list to confirm the algorithms you need are behind default features.

Frequently asked questions

Official sources

1. DioxusLabs/taffy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases