Declarative UI: Describe the 'What', Not the 'How'

WHY IT EXISTS Declarative UI was created to manage the overwhelming complexity of UI state in large applications. In older, imperative styles, developers had to manually track and update every individual UI element, leading to tangled, error-prone code. Declarative UI simplifies this by making the UI a direct, predictable reflection of the application's data state.

THE MENTAL MODEL Think of your UI code as a blueprint for a house, not a list of construction steps. You give the builder the final blueprint (the declarative UI). You don't give them a sequential list of instructions like "lay this brick, then that one." If you want to add a window, you simply provide a new blueprint with the window included. The builder then figures out the most efficient way to make the existing house match the new blueprint.

HOW IT WORKS In a framework like Flutter, your UI is a tree of widgets whose configuration (color, text, etc.) is derived from your app's state variables. When a state variable changes, the framework is notified. It re-runs the build logic for the affected parts of the tree, creating a new description of the UI. The framework then efficiently compares the new widget tree to the old one and only updates the pixels on screen that actually changed. You never tell it what to change, only what the new state is.

WHEN TO USE IT This is the default and mandatory paradigm when building with modern frameworks like Flutter, React, Jetpack Compose, or SwiftUI. It excels in applications with complex, dynamic state where the UI must react to data changes, user input, or network responses. It makes UI code more predictable and easier to reason about.

WHEN NOT TO USE IT Fighting this pattern in a framework like Flutter is counterproductive. However, for extremely simple, static websites with minimal interactivity, or when making tiny modifications to a legacy imperative codebase (like one using vanilla JavaScript or jQuery), the setup for a full declarative framework might be unnecessary overhead.

ONE CANONICAL EXAMPLE In Flutter, to show a loading spinner or a list of data, you don't write code to showSpinner() then hideSpinner(). Instead, you'd have a state variable like isLoading. Your UI code would contain logic like: if (isLoading) { return CircularProgressIndicator(); } else { return ListView(...); }. When your code sets isLoading = false, Flutter automatically removes the spinner and builds the list for you.