Add WASM/JS bindings via wasm-bindgen

[caweinshenker]

Objective

Adds JavaScript/TypeScript bindings for Taffy via wasm-bindgen, enabling use of Taffy's layout engine from JS/TS environments (browser and Node.js).

Fixes #928. Relates to #394.

The bindings live in bindings/wasm/ as a separate crate and produce a ~339KB optimized WASM binary.

What's included

• TaffyLayout class exposing tree creation, style setting, layout computation, and result retrieval
• Style parsing from plain JS objects with support for:
  • Display: flex, block, grid, none
  • Flexbox: flexDirection, flexWrap, flexGrow/Shrink/Basis, alignItems, justifyContent, etc.
  • CSS Grid: gridTemplateColumns/Rows (with fr/px/% units), gridColumn/Row placement
  • Box model: width/height, min/max variants, margin, padding, border (shorthand + per-side)
  • Position: relative, absolute with top/right/bottom/left insets
  • gap, overflow, aspectRatio
• Values accept numbers (points), strings ("50%", "auto", "1fr", "100px")

Usage

const { TaffyLayout } = require('taffy-wasm');

const layout = new TaffyLayout();
const child1 = layout.newLeaf({ width: 100, height: 50 });
const child2 = layout.newLeaf({ flexGrow: 1, height: 50 });
const root = layout.newWithChildren(
  { display: 'flex', flexDirection: 'row', width: 400, height: 200, padding: 10, gap: 10 },
  [child1, child2],
);
layout.computeLayout(root, 400, 200);
layout.getLayout(child1); // { x: 10, y: 10, width: 100, height: 50, ... }
layout.getLayout(child2); // { x: 120, y: 10, width: 260, height: 50, ... }

Security review

• 0 unsafe blocks in the binding code
• No network I/O, no file system access, no dynamic code execution
• All computation delegated to Taffy's existing Rust implementation
• WASM sandbox provides additional isolation
• 385 lines of pure glue code (JS object → Taffy Style struct translation)
• Full workspace test suite passes (cargo test --workspace)

AI disclosure

This code was generated with assistance from Claude (Anthropic). The binding architecture follows the same pattern as PR #394 (bindings/wasm/ crate with wasm-bindgen). All code has been reviewed, tested, and verified to compile and produce correct layout results for flexbox, block, and CSS grid layouts.

Context

The bindings are intentionally minimal — they expose the most commonly used CSS properties rather than attempting full coverage. Happy to expand based on feedback.

Tested with wasm-pack build targeting both web and nodejs, verified with flex/block/grid layout tests.

[caweinshenker]

Converting to draft — I should have filed the issue (#928) and waited for assignment before submitting. Happy to wait for maintainer feedback before proceeding. Will add tests in the meantime.

[nicoburns]

This looks broadly reasonable architectually. It'll be slower than is possible for a couple of reasons:

• Use of an object-based API and Reflect::get. Yoga's WASM have individual setters instead.
• Strings for enums. #394 used enums exposed over FFI so that these would be encoded as a number over the WASM boundary.
• Strings for numeric values (px, %, fr, etc) (this may not be slower, not 100% sure).

However, given how long this feature request has been sitting for, I think it's reasonable to get something that works out and worry about performance later.

---

A few other notes:

• #929 adds more robust/complete string parsing based on the cssparser crate to Taffy (which I had coincidentally been working on as part of #926). I would suggest basing this PR on top of that PR and making use of it's string parsing.
• Relatedly, you may want to make grid-template-columns and similar just one big string (or an option for that). That would allow support for repeat() to work.
• I notice that "measure functions" are not included in this PR. That might severely restrict the usefulness, as often you'll want to support things like text or images as "leaf nodes". Perhaps we ought to try to include that. #394 had a sketch of this. Can't remember how complete / working it is.

Finally, I would love to see some kind of usage example included in the PR as code. And also some instructions for publishing (would this be published to npm?). If possible for both node.js and web consumers. But if you've only been testing on one platform (web?) then a small runnable example for whatever platform you've been testing on would be fine.

[nicoburns]

These don't seem to be being used?

[nicoburns]

Is this true or AI generated?

[nicoburns]

start and end should map to the Start and End variants.

[nicoburns]

start and end should map to the Start and End variants.