Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Why declarative UI frameworks?

Why declarative UI frameworks?

In this talk I show you how traditional (imperative) UI frameworks work. We look at the implications of a component tree and its modification during runtime with regard to maintainability of your code. After that, we turn to declarative UI frameworks. We learn about their advantages over the classic approach, but also visit potential obstacles and pitfalls. All examples are based on the same use case, a simple click counter. Examples are presented in Java, JavaScript, Kotlin (Jetpack Compose), Swift (SwiftUI), and Dart (Flutter).

This talk was held during the online event betterCode() Flutter.

Thomas Künneth

May 24, 2022

More Decks by Thomas Künneth

Other Decks in Programming


  1. • Separation of UI definition and interaction handling ... •

    ... unclutters the code, making it easier to read and maintain • ... allows designers to create (parts of) the UI • Became popular in many UI frameworks
  2. • User interface still represented as a (component) tree ...

    • ... loaded at program startup • ... kept during execution • UI changes still implemented through … • … modifying properties • … changing the structure of the tree
  3. • Changing the UI necessary • when data shown to

    the user changes • upon navigation • Data and component tree live on their own • Important to keep both in sync Larisa Birta https://unsplash.com/photos/slbOcNlWNHA
  4. • To modify components, references must be maintained • Change

    may occur in different layers of the app (or on a different thread) • All this can lead to • difficult to find and fix bugs • spaghetti code • ... • Design patterns help mitigate such effects (MVC, MVVM, MVP, ...) Paolo Chiabrando https://unsplash.com/photos/3jt-1Va2eZo
  5. • UI frameworks learned to sync app and UI data

    through a binding mechanism • Read-only components just need one way bindings • Components with user interaction require two way binding zip_code Zip code
  6. Any change to the UI must be explicitly coded, either

    by changing component properties, or by modifying the tree itself Levi Meir Clancy https://unsplash.com/photos/KbPVj7knbTU
  7. Tell React to render a component The component is based

    on state Declaration of the UI is based on state State changes are wrapped inside setState()
  8. A property wrapper Declaration of the UI is based on

    state State changes have no special syntax
  9. State is created and remembered Declaration of the UI is

    based on state State changes have no special syntax
  10. Based upon stateless or stateful widgets Stateless widgets declare UI

    inside build() Stateful widgets createState()
  11. • Declaration of the UI is based on state •

    Can be extracted into other methods for better reuse and readability State changes are wrapped inside setState() Stateless widgets have build(), too
  12. Declaration of the UI is based on state Simple styling

    based on parameters Complex styling based on composition over inheritance
  13. • User interface is declared based on state • No

    need to modify (transform) the existing component tree • UI updates itself upon state changes
  14. Alen Jacob https://unsplash.com/photos/wdxb9OOMQOs • Frameworks maintain internal representation of the

    user interface • Must make sure that state changes trigger updates • (Should be) irrelevant for the application developer • ... it is most of the time ...
  15. • Traditional UI frameworks are based on components • A

    component has a fixed set of properties to configure appearance and behaviour • Inheritance is used to modify or expand both • Several parents possible only with multiple inheritance
  16. • Declarative UI fromeworks may rely on components, too •

    They may even rely on properties to define appearance and behavior • But they favour combining small, reusable building blocks over inheritance
  17. Markus Spiske https://unsplash.com/photos/uqeaZXZkquw • UI is declared based on state

    • No need to keep references to UI elements to change properties or the tree • Composition over inheritance
  18. Markus Spiske https://unsplash.com/photos/uqeaZXZkquw • A lot of magic under the

    hood • No easy way to inspect UI hierarchy during runtime • Larger UIs lead to large amounts of code
  19. Markus Spiske https://unsplash.com/photos/uqeaZXZkquw • Declarative UIs still require careful coding

    • We still required established patterns to organize the code base • It is fun using them