The Elements of UI Engineering – Core Challenges and Trade‑offs

Original author: Dan Abramov

Translator: UC International R&D Jothy

Welcome to the “UC International Technology” public account, where we share high‑quality technical articles on client‑side, server‑side, algorithms, testing, data, frontend and more, including original and translated content.

In a previous article I mentioned acknowledging our knowledge gaps; this is not about solving trivial problems but about exploring a broad field.

I believe you can start learning anytime, anywhere, without a strict sequence, though gaining expertise is important. Personally, I’m most interested in creating user interfaces.

I often reflect on what I know and find valuable. While I’m familiar with technologies like JavaScript and React, the insights gained from experience are far more valuable, and this is my first attempt to categorise them.

There are many “learning roadmaps” online that compare libraries and frameworks across years—Vue vs. React vs. Angular, Redux vs. Rx, Apollo vs. REST vs. GraphQL—making it easy to get lost, especially if the author’s advice is wrong.

My biggest learning breakthrough didn’t come from a specific technology but from solving concrete UI problems. Sometimes a library or pattern helps; other times I devise my own solution, with varying success.

This article focuses on the problem side: understanding the issue, practising a solution, and applying different strategies, which together provide the most valuable learning experience.

If you have built user interfaces, you have likely faced the following challenges. I encourage you to try building a tiny app without any libraries, iteratively refactor it, and solve problems directly. No universal solution exists; learning comes from exploring trade‑offs.

Consistency: Keeping UI state synchronised across multiple components (e.g., a “like” button that updates text, background, and server‑side data) while handling concurrent updates from other users.

Responsiveness: Delivering visual feedback within 100 ms for interactions; handling longer operations with indicators while avoiding jarring layout shifts.

Latency: Managing computational and network delays, handling asynchronous data loading gracefully without freezing the UI or showing endless spinners.

Navigation: Preserving UI state across page transitions (e.g., keeping search input when switching tabs) and restoring context when returning.

Caching/Expiration: Using local caches to speed up back‑navigation while ensuring stale data is refreshed and handling cache invalidation correctly.

Entropy (State Explosion): Dealing with the combinatorial explosion of possible UI states and transitions, and keeping visual output predictable.

Prioritisation: Balancing competing resource demands (CPU, network, screen real‑estate) among independent components, and avoiding “everything is important” dead‑locks.

Accessibility: Making applications usable for people with disabilities, such as low‑vision users, by following established accessibility practices.

Internationalisation: Supporting multiple languages and right‑to‑left layouts without sacrificing latency or responsiveness.

Transport: Choosing appropriate delivery formats and sizes (native app bundles vs. web app payloads) and optimising data transfer based on usage patterns.

Resilience: Isolating rendering failures so that a crash in one component doesn’t bring down the entire feed.

Abstraction: Creating reusable abstractions that hide implementation details, preventing the re‑introduction of solved problems as the app grows.

There are many more issues not listed here—design‑engineer collaboration, debugging, testing, etc.—which could be covered in future posts.

The temptation is to reach for a specific UI library or data‑fetching tool, but I encourage you to imagine those libraries don’t exist and rethink the problem from first principles, implementing small prototypes and sharing them on GitHub.

These challenges appear at any scale, from tiny type‑ahead components to massive platforms like Twitter or Facebook.

Look at the extraordinary UI elements you admire, map them to the list above, and describe the trade‑offs developers made; then try recreating them from scratch.

Experimenting with these problems in small, library‑free apps is a powerful way to deepen your understanding of UI engineering; I recommend anyone interested in the trade‑offs to give it a try. ❤️

English original: https://overreacted.io/the-elements-of-ui-engineering/