Server Driven UIs: the future of cross-platform rendering
summary
Server-driven UIs send a server-crafted screens and sections schema plus a shared data model and design tokens that clients interpret; common examples include Airbnb, Duolingo and Reddit using server templates, component types and unique ids to avoid duplication. Claims: one rendering codebase cuts binary size and enables rapid A/B testing and fixes; tradeoffs are payload size, version skew and fallbacks, weak offline support and poor medium/complex animations causing response bloat.
AI-written summary · about
chapters (17)
- 0:00Server-driven UIs intro
- 1:07Origin and evolution
- 3:16Architecture overview
- 5:28Designing data models
- 6:34Design systems and tokens
- 7:20Versioning and compatibility
- 9:27Actions and event handling
- 11:19API response structure
- 12:24Airbnb case study
- 17:06Unique IDs importance
- 18:33Advantages of server-driven UIs
- 21:24When not to use SDUI
- 23:32SDUI vs client-driven
- 26:00Getting started with SDUI
- 27:35Q&A: DSL and localization
- 29:04Q&A: Local actions handling
- 31:17Q&A: Backend navigation
related talks
29mServer Driven UI (BFF)
18mServer-Driven UI: Building Dynamic React Applications
18mServer Driven UI on Mobile
35mHow you can Server-Render without Rendering on the Server
33mA page out of Server driven UI on Android
43mServer-driven UI on the Web — Describe Your Frontend, Don’t Write It
24mUsing Server Driven UI to rapidly iterate on Android and Across Platforms
45mBuilding Server Driven UI in iOS