Lynx.js, a technology from ByteDance, is known for its distinctive two-thread model that splits UI work from application logic. This stream serves as a learning ground for Łukasz Chludziński and Kewin Wereszczyński as they work to understand how this model behaves in practice. With a fresh project and the official docs in hand, they begin mapping out how Lynx approaches execution and where the boundaries between threads appear.

A closer look at the two‑thread model

Lynx runs user code on a background engine, while the main thread handles UI work. This separation shapes how the application behaves from the start. As they explore component examples, the hosts notice how thread‑specific bindings show up in the API. Props like main-thread:bindscroll appear directly in autocomplete, making the thread boundary visible inside the component interface. The model encourages thinking intentionally about where logic executes.

Working through the tutorial code

The team proceeds through the official gallery tutorial, pulling in assets, reviewing JSX structure, and following how layout and CSS flow through the engine. Components look familiar, and the presence of thread‑aware props adds a new dimension to the mental model. Some steps require troubleshooting-type definitions, imports, and file placement-but each adjustment reveals more of how Lynx expects projects to be organized.

Understanding how interactions flow

As they build up the example, the role of main‑thread bindings becomes easier to see. Interactions that need direct access to UI state rely on main‑thread directives, while everything else stays on the background thread. Seeing these decisions in context helps clarify how developers reason about interaction timing and responsiveness in Lynx.

What comes next

This session establishes the foundation for understanding Lynx’s execution model. Part two continues the exploration, focusing on how work moves between threads and how interaction logic fits into the overall design.