Lynx UI frameworks

Lynx ships five native elements and leaves everything above them to you. <view>, <text>, <image>, <scroll-view>, and <list> cover layout and primitive rendering, so every application builds the tier web developers take for granted, meaning dialogs that trap focus, sheets that respond to a drag, and sliders that track a gesture without dropping frames.

Two libraries fill that tier today, and they bind to different frameworks, so the choice falls out of a decision you already made about React or Vue. If you know which framework you are writing, skip to choosing between them.

The libraries

lynx-ui, the official ReactLynx library

@lynx-js/lynx-ui is the Lynx team's own component library for ReactLynx. It is headless, and it ships one npm package per component rather than a single barrel, so you only pay for what you import. The published set covers Button, Checkbox, Dialog, Draggable, FeedList, Form, Input, LazyComponent, List, Overlay, Popover, Presence, RadioGroup, ScrollView, Sheet, Slider, Sortable, SwipeAction, Swiper, and Switch, plus a shared common package underneath them.

The same team builds the runtime, so behavior tracks Lynx SDK changes closely, and it requires LynxSDK 3.2 or newer. If you write ReactLynx, start here.

It styles nothing, and it does not support Vue. No ReactLynx equivalent to shadcn/ui or Vant sits on top of it yet, so the visual layer is still work you do yourself.

Vy UI, for Vue Lynx

Vue Lynx is a Vue 3 custom renderer that cannot consume React components, so lynx-ui does not help there. Vy UI fills the gap in two layers.

@vyui/core is the headless layer, 47 primitives covering overlays and dialogs, menus and popovers, form controls, navigation, and gestures. Swiper, SwipeAction, Sortable, Draggable, FeedList, and ScrollView share one main-thread gesture core, so a drag never round-trips through the background thread.

@vyui/kit is the styled layer, 48 components on those primitives themed through Tailwind Variants. A three-tier semantic token system flips the whole set into dark mode through a single class instead of per-component dark: variants, and a shadcn-style CLI copies component source into your repository when you would rather own the code.

Vy UI is alpha and Vue Lynx is earlier than that, so pick it once you have settled on Vue and accepted that APIs will move. It is MIT licensed and community-maintained rather than official.

Skipping the libraries entirely

The obvious objection is that you could write these components yourself, and for a small application that holds up better than I would like. Lynx gives you real CSS in external stylesheets, and <list> is already a virtualized recycler.

The cost lands in behavior rather than appearance. A dialog needs focus and dismissal handling, a bottom sheet needs velocity-aware drag physics on the main thread, and a select needs keyboard and screen-reader wiring that Lynx does not infer. Those take weeks and then break on one platform.

Choosing between them

Pick ReactLynx and lynx-ui if your team writes React and you are willing to build the styling layer yourself. This is the better-supported path today and most of the ecosystem assumes it.

Pick Vue Lynx and Vy UI if your team writes Vue and rewriting into React is not a trade you want. You get a styled layer that ReactLynx has no equivalent for, and a younger runtime underneath it. The Vue Lynx guide covers what that runtime supports.

Both compile down to the same native Lynx elements on iOS, Android, and web, so neither choice commits you to a different rendering model.

Where the ecosystem is thin

Three gaps apply to every option on this page.

Accessibility on web is incomplete in a way it is not on native. Lynx emits accessibility-* properties that iOS VoiceOver and Android TalkBack consume directly, but browsers ignore them, so a web screen reader sees generic boxes unless a library mirrors them into ARIA. Vy UI documents this as an open gap.

Keyboard input on web is similarly unhandled, because Lynx was designed for touch and the browser target inherits that. Neither library wires Escape-to-dismiss or arrow-key menu navigation by default.

Internationalization is early. Intl is not fully available in the Lynx runtime, so date and number formatting depend on polyfills and RTL layout coverage is partial.

None of this is a reason to avoid Lynx. It is a reason to check the components you need against the targets you ship to, instead of assuming web parity with native.

Related