beorn/flexily

Flexily

Pure JavaScript flexbox layout engine with Yoga-compatible API.

Composable API (recommended):

import { createFlexily, FLEX_DIRECTION_ROW } from "flexily"

const flex = createFlexily()
const root = flex.createNode()
root.setWidth(80)
root.setFlexDirection(FLEX_DIRECTION_ROW)

const label = flex.createNode()
label.setTextContent("Hello") // auto-measured: 5 wide

const content = flex.createNode()
content.setFlexGrow(1)

root.insertChild(label, 0) root.insertChild(content, 1) flex.calculateLayout(root, 80, 1) // label: 5 wide, content: 75 wide

**Low-level Yoga-compatible API:**

import { Node, FLEXDIRECTIONROW, DIRECTIONLTR } from "flexily"

const root = Node.create() root.setWidth(100) root.setFlexDirection(FLEXDIRECTIONROW)

const child = Node.create() child.setFlexGrow(1) root.insertChild(child, 0)

root.calculateLayout(100, 100, DIRECTIONLTR) console.log(child.getComputedWidth()) // 100

## Why Flexily?

[Yoga](https://yogalayout.dev/) is the industry standard flexbox engine, used by React Native, Ink, and thousands of apps. It's mature and battle-tested. But it's C++ compiled to WASM, and that creates real problems for JavaScript applications:

**Async initialization.** Yoga requires `await Yoga.init()` before creating any nodes. No synchronous startup, no use at module load time, no use in config files or build scripts. For CLIs that should start instantly, this adds latency and complexity.

**WASM boundary crossing.** Every method call (`setWidth`, `setFlexGrow`, etc.) crosses the JS-to-WASM boundary. Node creation is ~8x more expensive than a JS object. For TUIs that rebuild layout trees per render, this dominates.

**Memory growth.** WASM linear memory grows but never shrinks. Yoga's yoga-wasm-web had a known memory growth bug where each node allocation permanently grew the WASM heap. In long-running apps, this caused [120GB RAM usage in Claude Code](https://github.com/anthropics/claude-code/issues/4953).

**Debugging opacity.** You can't step into WASM in a JS debugger. When layout is wrong, you get a computed number with no way to inspect the algorithm's intermediate state. Flexily is readable JS — set a breakpoint in `layout-zero.ts`.

No tree-shaking. The WASM binary is monolithic. You get the entire engine even if you use a fraction of the features.

Facebook's original pure-JS flexbox engine (css-layout) was abandoned when they moved to C++. flexbox.js exists but is unmaintained and missing features. Flexily fills the gap: comprehensive CSS flexbox support, Yoga-compatible API, pure JS, zero WASM.

Who Should Use Flexily

Most developers should use a framework built on Flexily, not Flexily directly. Flexily is for:

• Framework authors building a TUI or layout framework that needs a JS layout engine
• Canvas/game developers who need flexbox for non-DOM rendering
• Specialized tools where you need direct control over layout computation
• Anyone replacing Yoga who wants a drop-in pure-JS alternative

Building a terminal UI? Use silvery, which uses Flexily by default. You get React components, hooks, and layout feedback without touching the low-level API.

Composable API