Lynx UI frameworks

Lynx ships primitives and leaves everything above them to you. <view>, <text>, <image>, <scroll-view>, and <list> are the core built-ins, with <page> and <frame> beneath them, and the separately linked XElement package adds <input>, <textarea>, <overlay>, <svg>, <refresh>, and six more. Nothing in either set is a dialog that traps focus, a sheet that responds to a drag, or a slider that tracks a gesture without dropping frames, so every application builds the tier web developers take for granted. The Vue Lynx guide has the whole element set with the constraints on each.

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 alongside the 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.

Headless means the visual layer stays yours, and no ReactLynx equivalent to shadcn/ui or Vant sits on top of it yet. It targets React, so a Vue project cannot consume it.

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, 45 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, though its component surface has held steady across recent releases; Vue Lynx labels itself pre-alpha, and that is where the movement actually comes from. Pick it once you have settled on Vue. 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.

Check these against your targets

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