Ansh

The problem with porting

Component and motion libraries almost always begin life in one framework. The React version ships first, gets used, gets refined. Some months later a Vue port arrives — written by different people, on a different schedule, against a specification that mostly lives in the original source code.

What follows is predictable. A spring that feels right in the React build drifts in the Vue port, because someone re-implemented the physics from the outside and got close rather than exact. A focus trap handles a case in one framework that the other has never heard of. Six months on, the two implementations have diverged enough that nobody can say with confidence which one is correct — and every bug report has to be triaged twice.

The root cause is structural, not a matter of discipline. If the behaviour lives inside framework-specific code, then supporting a second framework means duplicating the behaviour, and duplicated behaviour drifts. No amount of care prevents that; it only slows it down.

Inverting the order

Ansh was built the other way round. The engine came first.

@ansh-ui/core contains every spring, every easing curve and every colour computation, and it imports neither React nor Vue. It is not a shared utilities package that grew out of the React build — it is the actual implementation, and the framework packages are bindings over it.

That distinction matters more than it sounds. A utilities package is something a framework implementation uses; the interesting logic still lives upstairs, and a second framework re-implements that logic. An engine is where the logic is; a binding has nowhere to put a divergent copy, because there is nothing left to diverge about. When a React binding and a Vue binding both ask the engine where a spring should be at 120 milliseconds, they get the same number, because it is the same function.

The bindings handle exactly what is genuinely framework-specific: lifecycle, refs, reactivity, and how a component is described in that ecosystem. Everything else is delegated. And because there is no primary framework, there is no port to fall behind — React and Vue are built and tested in the same pass.

Motion that does not depend on the frame rate

Most animation libraries integrate a spring numerically: take the current position and velocity, step forward by however long the last frame took, repeat. It works, and it is subtly frame-rate dependent. The same animation on a 60Hz laptop, a 120Hz phone and a machine dropping frames under load produces three slightly different curves, and it is not reproducible in a test — which is why so few motion libraries have meaningful tests of their motion.

Ansh solves springs in closed form instead. Given the spring's parameters and a time, it evaluates the position directly. Frame rate stops being an input. The same animation is identical everywhere, replaying it produces the same numbers, and a test can assert on the value at 200ms without rendering anything.

Forty easing curves ship alongside, defined in the engine so both frameworks reference the same definitions rather than each carrying a table of approximations.

Colour computed in OKLCH

Component libraries generate colour constantly — a hover state, a disabled state, a border derived from a fill. Do that arithmetic in the colour space the web has traditionally used and the results are uneven in a way that is hard to name but easy to see: lightening a yellow and lightening a blue by the same amount produces two changes that do not feel equal, because the space is not perceptually uniform.

OKLCH is. Working in it means a derived state is as far from its base colour as the numbers say it is, consistently across every hue. Themes generated from a single seed colour stay balanced, and the components in the library stay coherent with each other rather than needing per-hue corrections.

One clock for the whole page

The natural way to animate a component is to have it request its own animation frames. It works fine for one component and degrades as the page fills up: fifty animated elements means fifty independent loops, each unaware of the others, all competing for the same frame.

Ansh runs a single ticker that drives every active animation and works to an adaptive frame budget. Scheduling is a property of the page rather than of each component, which is what allows a lot of motion to coexist without any individual piece needing to know how busy the page is.

Where it landed

57 components. 40 easing curves. Zero runtime dependencies — the engine implements its own maths rather than pulling in a physics or colour library, which keeps the install size predictable and means the behaviour cannot change underneath a consumer because a transitive dependency shipped a minor version.

The result worth naming is not any of those numbers, though. It is that "does this behave the same in Vue?" stopped being a question anyone needs to ask.