I've been looking into this, and it looks like wasm support might not be too difficult:

• The predecessor to this library stretch had wasm bindings (source here and docs here)
• The setup seems to be a vanilla wasm-pack setup
• The meat of the bindings aren't all that long (650 lines with quite a bit of boilerplate). And it looks like some of the boilerplate could be cut down on by adding #[wasm_bindgen] directly to taffy types (behind a feature flag) rather than duplicating them (if we are willing to bring in another dependency then num-derive and/or serde-wasm-bindgen could further cut down on boilerplate)

Awesome! I'd be happy to review that.

I've been looking into this, and it looks like wasm support might not be too difficult:

• The predecessor to this library stretch had wasm bindings (source here and docs here)
• The setup seems to be a vanilla wasm-pack setup
• The meat of the bindings aren't all that long (650 lines with quite a bit of boilerplate). And it looks like some of the boilerplate could be cut down on by adding #[wasm_bindgen] directly to taffy types (behind a feature flag) rather than duplicating them (if we are willing to bring in another dependency then num-derive and/or serde-wasm-bindgen could further cut down on boilerplate)

I found napi-rs used by resvg-js and it's pretty good binding with node too.

I found napi-rs used by resvg-js and it's pretty good binding with node too.

napi-rs does indeed look like a good option for node bindings (which yoga also has), however I don't think that would give us wasm support. So I would consider that a separate feature request.

For what its worth, I have ported the C bindings from stretch to taffy. Pretty minor API changes overall, which makes me think porting the old WASM bindings would be very straightforward.

@xavierzwirtz Yeah, when I looked into this recently, it looked like C and WASM would be both be quite straightforward. But stretch's Swift and especially it's Kotlin bindings looked quite a bit more involved. Perhaps we ought to create a new meta issue for language bindings. It would be good to determine which languages have the most interest, and perhaps come up with a strategy that can allow us to re-add the bindings while keeping the maintenance burden manageable.

I suspect focussing on C and WASM first might be a good strategy. WASM effectively gives us Node support too (albeit with a performance penalty), and I suspect a good C API would make it easier for other people to write their own bindings for other languages, which generally support C FFI.

Some WASM bindings for Taffy based on the Stretch bindings are now available here https://github.com/load1n9/gelatin