Dynamic UI Implementation in Qunar's Large Client: Architecture, DSL Design, and Template Management

Before introducing dynamic UI, Qunar's large‑client homepage was built entirely with native code, which, while ensuring cold‑start performance, suffered from long iteration cycles and high fix costs when issues arose.

The team set four goals for a dynamic UI: native‑level performance, hot‑update capability for real‑time publishing and rollback, low‑learning‑curve editing for front‑end developers, and data‑binding with decoupled templates and business models.

After evaluating React Native (good flexibility but insufficient performance) and Flutter (high performance but lacking hot‑update features), the team selected a Native + DSL solution, leveraging iOS Yoga and Android Litho for rendering while defining a domain‑specific language (DSL) to describe UI templates.

The DSL, a specialized language focused on UI layout, enables developers to write JSON‑based, nested templates and supports custom dynamic expressions; it offers performance benefits by keeping component initialization, layout, and rendering native, while allowing easy customization and low learning cost for developers familiar with Flexbox.

Implementation details include using Yoga on iOS, Litho on Android, a JSON‑driven declarative UI model, and a custom expression engine that parses expressions like ${data.imageList[0].imageUrl} via an AST‑based approach, supporting string comparison, null checks, arithmetic, concatenation, and ternary operations such as ${tripData.depTerminal? tripData.depAirport+tripData.depTerminal: tripData.depAirport} .

The SDK is divided into four modules—DSL parsing, data binding, virtual DOM processing, and data validation—which together transform templates and data into renderable nodes; a virtual node layer enables layout calculation before actual UI component creation, saving resources.

Template management is handled by a dedicated platform that supports editing, gray‑release, publishing, version control, and scene‑based backend restrictions, ensuring that only appropriate data is delivered to the client.

For real‑time preview, the team chose a local Node.js service that watches template files, establishes a WebSocket connection with the client, and refreshes the UI instantly, providing a true "what‑you‑see‑is‑what‑you‑get" experience.

The solution has been rolled out to the homepage's travel‑card component and other widgets, addressing issues such as gradient backgrounds and platform‑specific defaults, and enabling iterative feedback loops between SDK and business teams.

Results include hot‑publishing of homepage features without full releases, roughly 50% reduction in development effort across iOS and Android, JIT development with instant preview, and near‑zero learning cost for DSL adoption.

Future work will extend the DSL with iterator support for variable‑length lists and improve template synchronization by moving from hard‑coded templates to cached file‑based resources.

In conclusion, the dynamic UI experiment highlighted both challenges and significant gains, offering valuable insights for front‑end engineers facing rapid iteration and performance constraints.