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
   

   View Slide

2. Ibrahim Boran
   https://unsplash.com/photos/iYkqHp5cGQ4
   What‘s wrong with
   existing UI frameworks?
   

   View Slide

3. Provide an app frame
   Build a component tree
   Update UI based on data
   

   View Slide

4. Define state
   Modify state and update UI
   Create and configure
   components
   

   View Slide

5. Define state
   Modify state
   Update UI based on state
   Connect code to the UI tree
   

   View Slide

6. Declare a tree of components
   Define parts of visual appearance
   Connect UI elements to code
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

10. Claudio Schwarz
    https://unsplash.com/photos/qjX0QBtDXto
    Almos Bechtold
    https://unsplash.com/photos/AJ_Mou1FUS8
    manually with magic
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

14. Ryunosuke Kikuno
    https://unsplash.com/photos/KnQ980sdlqU
    Works well in small projects, but doesn‘t
    really scale
    

    View Slide

15. George Rosema
    https://unsplash.com/photos/yg8pLPTAY8M
    Declarative UI frameworks
    

    View Slide

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()
    

    View Slide

17. A property wrapper
    Declaration of the UI is based on state
    State changes have no special syntax
    

    View Slide

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

    View Slide

19. Based upon stateless or stateful widgets
    Stateless widgets declare UI inside build()
    Stateful widgets createState()
    

    View Slide

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
    

    View Slide

21. Declaration of the UI is based on state
    Simple styling based on parameters
    Complex styling based on
    composition over inheritance
    

    View Slide

22. • User interface is declared based on state
    • No need to modify (transform) the
    existing component tree
    • UI updates itself upon state changes
    

    View Slide

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 ...
    

    View Slide

24. Composition over inheritance
    

    View Slide

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
    

    View Slide

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
    

    View Slide

27. View Slide

28. View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

32. Thank you!
    thomas@thomaskuenneth.eu
    @tkuenneth
    @tkuenneth
    https://www.thomaskuenneth.eu/
    @tkuenneth
    

    View Slide