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.

Transcript

1. Why declarative UI frameworks? Thomas Künneth, Snapp Mobile Sven Mieke https://unsplash.com/photos/fteR0e2BzKo
2. Ibrahim Boran https://unsplash.com/photos/iYkqHp5cGQ4 What‘s wrong with existing UI frameworks?
3. Provide an app frame Build a component tree Update UI based on data
4. Define state Modify state and update UI Create and configure components
5. Define state Modify state Update UI based on state Connect code to the UI tree
6. Declare a tree of components Define parts of visual appearance Connect UI elements to code
7. • 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
8. • 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
9. • 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
10. Claudio Schwarz https://unsplash.com/photos/qjX0QBtDXto Almos Bechtold https://unsplash.com/photos/AJ_Mou1FUS8 manually with magic
11. • 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
12. • 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
13. 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
14. Ryunosuke Kikuno https://unsplash.com/photos/KnQ980sdlqU Works well in small projects, but doesn‘t really scale
15. George Rosema https://unsplash.com/photos/yg8pLPTAY8M Declarative UI frameworks
16. 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()
17. A property wrapper Declaration of the UI is based on state State changes have no special syntax
18. State is created and remembered Declaration of the UI is based on state State changes have no special syntax
19. Based upon stateless or stateful widgets Stateless widgets declare UI inside build() Stateful widgets createState()
20. • 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
21. Declaration of the UI is based on state Simple styling based on parameters Complex styling based on composition over inheritance
22. • User interface is declared based on state • No need to modify (transform) the existing component tree • UI updates itself upon state changes
23. 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 ...
24. Composition over inheritance
25. • 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
26. • 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
29. 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
30. 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
31. 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
32. Thank you! thomas@thomaskuenneth.eu @tkuenneth @tkuenneth https://www.thomaskuenneth.eu/ @tkuenneth