What is Vue Lynx

Vue Lynx is a Vue 3 custom renderer that targets Lynx, the cross-platform framework ByteDance open-sourced in March 2025 and uses in parts of TikTok. Your components stay Vue with <script setup>, the Composition API, and ordinary reactivity, and they render to native views on iOS and Android instead of to the DOM. The same source runs on the web through Lynx's browser runtime.

Vue Lynx reuses @vue/runtime-core rather than reimplementing Vue, so reactivity, lifecycle, provide/inject, slots, and the component model are the same code running under a different renderer.

What changes

Four differences show up in the first hour, and none touch the component model.

The elements are Lynx elements. There is no <div> and no <span>. Layout goes in <view>, text has to sit inside a <text> element rather than loose in a container, images use <image>, scrolling uses <scroll-view>, and long lists use <list>, which is a native recycler rather than a rendered array.

Your code runs on a background thread. The main thread does nothing but render and handle high-priority input, and your JavaScript runs beside it. A Lynx app can paint its first frame before your component code finishes executing, and a gesture that tracks a finger at 60fps has to run in a main-thread worklet rather than a normal event handler. Most components never touch this, and drag-driven ones always do.

Browser globals are gone. There is no window and no document, so any library reaching for them needs adapting or replacing. That rules out most of the existing Vue component ecosystem, which is why a Lynx-specific component library has to exist.

Styling is real CSS, with limits. Lynx parses actual stylesheets rather than style objects, so selectors, custom properties, media queries, and transitions all work. The native engine resolves only one level of var() indirection, and a few properties behave differently from the browser.

Vue Lynx and ReactLynx

ReactLynx came first and remains the reference frontend, so the documentation, examples, and the official @lynx-js/lynx-ui library all assume React. Lynx itself is framework-agnostic by design, and the Lynx team has said non-React frameworks already account for roughly half of its usage internally.

What Vue Lynx fights is ecosystem age. Its API surface still moves, and ReactLynx libraries cannot be consumed from Vue because they are React components. I would take ReactLynx for the most-supported path today, and Vue Lynx when your team writes Vue and a rewrite is not on the table.

Where components come from

Lynx gives you five elements, so dialogs, sheets, selects, toasts, sliders, and every gesture surface are application code unless a library provides them.

Vy UI is that library, in two layers. @vyui/core ships 47 headless primitives handling state, focus, keyboard, and gesture physics while leaving styling to you, and @vyui/kit ships 48 styled components on top of them, themed through Tailwind Variants. Drop from kit to core wherever the styled version stops fitting.

The Lynx UI frameworks comparison maps this against the ReactLynx options.

Starting a project

Install the packages into an existing Vue Lynx application:

npm i @vyui/core @vyui/kit

A styled component then works like any other Vue component:

<script setup>
import { VyButton } from '@vyui/kit'
</script>

<template>
  <view>
    <VyButton>Continue</VyButton>
  </view>
</template>

Two pieces of setup are specific to Lynx, and Installation covers both. The bundler needs includeWorkletPackages so main-thread gesture code is registered, and Tailwind needs the Vy UI preset for the semantic tokens behind theming and dark mode.

What to expect on each target

Native iOS and Android are the targets Lynx was designed for, so accessibility works through the platform screen readers without extra wiring, gestures run on the main thread, and animations are native.

Web is a real target rather than a preview, and the component previews throughout these docs are the web runtime running real component code. It is not at parity. Lynx dispatches raw mouse events without synthesizing touch from them, so drag surfaces need explicit mouse handling, which Vy UI ships for every gesture component. Keyboard navigation is not wired, and the accessibility-* properties that native screen readers consume are ignored by browsers.

Those gaps are specific rather than uniform, so check the components you depend on against your targets.

Related