• Home
  • Events
  • About
  • MVC is dead – what comes next? – Part 2

    November 2nd, 2016

    The first part of this series gave an overview of the key concepts and listed some of the main advantages of using functional reactive programming techniques in UI development. Future articles we will focus on different components that are involved, starting today with the State component, a key ingredient of functional reactive UI programming.
    MVC vs FRP Data Structures
    In MVC we differentiate between domain model and UI state, in functional reactive UI programming everything is part of the State.

    Single Source of Truth

    In MVC applications we usually differentiate between the domain model and UI state. For example if we implement the TodoMVC application (see screenshot below) following some kind of MVC-pattern, our model will probably only consist of a list of ToDo-entries, because they define our domain. But the model would not keep the current entry in the input field (“What need to be done?”). And it would probably also not contain the selected filter.

    Screenshot TodoMVC
    Screenshot of TodoMVC


    The State component of a functional reactive application on the other hand contains the complete state of the application. The domain model and the UI state are typically merged into a single data structure – a tree. The picture at the beginning of the article shows the difference between both approaches.

    Why is this important?

    If we have all state in a single place, i.e. a single source of truth, we can implement the View as a pure function.

    This has many advantages: it is easier to understand, easier to reason about, and easier to test.



    The second important characteristic of the State is its immutability. We cannot change it.

    If the state of the application changes, we have to create new data structures.

    This may sound like a terrible waste. If we store the whole state in a tree and we have to create a new instance every time something changes, how can this be efficient? The trick is, that we do not have to copy the whole tree, but only a small part.

    Modifying an immutable tree
    When modifying a single node of an immutable tree, only a small number of nodes have to be replaced.


    Imagine our applications state is stored in the tree shown above. We want to change the property of the green leaf node. The node itself has changed, therefore we need to create a new instance. We also need to create a new instance for the parent node, because one of its children has changed. But the other child of that parent has not changed and we can reuse it by referencing it from the new parent node. The same is true for all the other parent nodes up to the root node. We need to create a new instance for each parent on the path to the top, but we can reuse the other children. In the diagram we only have to create new instances for the blue nodes, which are only a small fraction of the tree in particular if the tree becomes huge.

    Implementing State in Java

    I have recently started an experiment to explore how the principles from functional reactive UI programming could be applied to Java and JavaFX. You can find the current state of the mini-framework ReduxFX and a sample application at GitHub.

    Implementing the State component in Java is straight-forward. All elements of the state can be implemented as simple, immutable POJOs.

    Unfortunately the standard-collections in the JDK are not really suitable for immutability. But luckily there are several alternatives out there, that you can use instead. My personal favorite at this point are the collections in Javaslang, which offer several additional benefits besides being immutable.

    The code below shows the class AppModel from the sample project in ReduxFX. The property todos is of type Seq, which is part of Javaslang. Seq is similar to Iterable in the JDK, because it is the supertype of all sequential data structures in Javaslang (though Seq offers much more functionality). In other words todos is a list of TodoEntries.

    The property newTodoText contains the text stored in the TextField for new todo-entries. Last but not least, the property filter stores the current filter (ALL, ACTIVE or COMPLETED).


    State in functional reactive UI programming is similar, but not the same as the Model in a classical MVC application. It contains all state, including UI state, and not only the domain model. In many frameworks the state is stored in a single data structure, usually in a tree. Another key requirement is immutability. Implementing the State component in Java is straightforward with immutable POJOs.

    The next part will cover the View-function, which translates the State to the actual UI. If you have any questions, ideas or thoughts, please leave a comment. Also do not forget to checkout my JavaFX sample ReduxFX.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    MVC is dead – what comes next?

    October 10th, 2016

    React.js, Elm, Cycle.js, and other UI frameworks introduced a new way of building user interfaces. By applying principles from functional reactive programming to UI development, they even changed how we think about user interfaces. In no time, these approaches have simply smashed the seemingly inevitable dominance of MVC and its siblings (MVP, MVVM etc.). This article, which is the first in a series, will give a brief introduction into this new way of building UIs and list some of the advantages it has over traditional approaches. These factors are so strong, that in my opinion there is a good chance that we are right now witnessing the end of the MVC-era.

    Graph showing the cyclic dependency between DOM Driver, ActionCreator, Updater, and View()

    Concept of functional reactive UI development

    On the face of it, frameworks like React.js with the Redux-architecture, Elm, and Cycle.js seem quiet different. Redux applications initially appear to be similar to regular JavaScript application, perhaps with a strong focus on functional programming. Elm-applications come with their own language, while Cycle.js applications consist of reactive streams only which are knotted together in astonishing ways.

    But under the hood, all of these frameworks have something in common: the essence of functional reactive UI development.

    The picture above shows a rough overview of the concepts, which are shared between pretty much all modern UI frameworks that foster reactive programming. First thing to note is that everything – all changes, events, and updates – flow in a single direction to form a cycle. This article will give just a brief explanation of the cycle, while later articles will go into more details.

    Functional Reactive UI-Development

    The cycle consists of four data-structures (State, Virtual DOM, Event, and Action) and four components (View()-Function, DOM-Driver, ActionCreator, and Updater). The DOM-Driver is provided by the framework, while the other components have to be implemented by the application developer.

    Let’s assume our application, a todo-list, is already running for a while and the user presses a button to create a new entry in the todo-list. This will result in a button-clicked event in the DOM, which is captured by the DOM-Driver and forwarded to one of our ActionCreators.

    The ActionCreator takes the DOM-event and maps it to an action. Actions are an implementation of the Command Pattern, i.e. they describe what should be done, but do not modify anything themselves. In our example, we create an AddToDoItemAction and pass it to the Updater.

    The Updater contains the application logic. It keeps a reference to the current state of the application. Every time it receives an action from one of the ActionCreators, it generates the new state. In our example, if the current state contains three todo-items and we receive the AddToDoItemAction, the Updater will create a new state that contains the existing todo-items plus a new one.

    The state is passed to the View()-Function, which creates the so-called Virtual DOM. As the name suggests, the Virtual DOM is not the real DOM, but it is a data-structure that describes how the DOM should look like. The code snippet above shows an example of a Virtual DOM for a simple <div>. A later article will explain the Virtual DOM and its advantages in detail.

    The Virtual DOM is passed to the DOM-Driver which will update the DOM and wait for the next user input. With this, the cycle ends.


    Functional reactive UI Development has three major advantages over traditional approaches, all of them are huge: straightforward testing, a comprehensive flow of events, and time travels (yes, seriously).

    Straightforward testing

    The View()-Function and the ActionCreators are simple mappings, while the Updater performs a fold (also often called a reduce) on the Actions it receives.

    All components are pure functions and pure functions are extremely easy to test.

    The outcome of a pure function depends only on the input parameters and they do not have any side effects. To test a pure functions, it is sufficient to create the input parameter, run the “function under test” and compare the outcome. No mockups, no dependency injection, no complex setup, and no other techniques are necessary that take the fun out of testing.

    Comprehensive Flow of Events

    Reactive programming is a lot of fun – except when it is not. The control flow of graphical user interfaces is inherently event-based. An application has to react to button-clicks, keyboard input, and other events from users or servers. Applying reactive techniques, be it the Observer Pattern, data-bindings, or reactive streams, comes naturally.

    Unfortunately these techniques come with a price. If a component A calls a component B, it is simple to see the connection in your IDE or debugger. But if both components are connected via events, the relationship is not as obvious. The larger the application becomes, the harder it gets to understand its internals.

    The architecture of a functional reactive application avoids these problems by defining a simple flow of events that all components must follow.

    No matter how large your application grows, the flow of events will never change.

    Time Travel

    Functional reactive applications allow you to travel back and forth in time – at least in the context of your application. If we store the initial state and all actions, we can use a technique called “Event Sourcing”. By replaying the actions, we can recalculate every state the application was in. If we replay only the last n-1, n-2, n-3… actions, we can actually step back in time. And by modifying the recorded stream of actions while applying them, we can even change the past. As you can imagine this can be very handy during development and bugfixing.

    The first time-traveling debuggers have been built, but I think we have only started to understand the possibilities, and more amazing tools will be released in the future.


    So far we have only touched the surface of functional reactive UI development, but by now it should be clear that this approach has some tremendous advantages. Future articles will go deeper into the technical details, but also show the disadvantages (or let’s call them “yet-to-solve-challenges”), and show an example how the lessons learned can be applied to JavaFX applications.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Lazybones Template for Dolphin Platform Jumpstart

    March 31st, 2016

    As Hendrik stated rightfully in his post about the Dolphin Platform Jumstart maven archetype, Starting with a new technology is often hard.

    To make getting started with the Dolphin Platform in combination with Gradle easier for a broader audience, Maxim and me created a lazybones template for the jump start project of the Dolphin Platform during the last Hackergarten in Basel.

    It is based on the maven archetype (and adopting the actual example project from there) but is completely build with gradle and provides some other improvements like an integrated build for the polymer client.

    You can find it’s source project at https://github.com/canoo/dolphin-platform-lazybones-templates

    To actually use the template you need to have lazybones installed. The easiest way to get it is via SDKMAN.

    So first, let’s install that:
    $ curl -s http://get.sdkman.io | bash
    (Windows users: look for the Powershell version)

    Then, we can use it to install gradle and lazybones:
    $ sdk install lazybones $ sdk install gradle

    Next register the dolphin-platform-lazybones-templates repository with Lazybones‘ config file. Edit

    bintrayRepositories = [ “canoo/dolphin-platform-lazybones-templates”, “pledbrook/lazybones-templates” ]

    If everything is fine, issuing the command
    $ lazybones list

    should list the Dolphin Platform template:
    Available templates in canoo/dolphin-platform-lazybones-templates dolphin-platform-spring-boot

    Now, we can use it to create a new Dolphin Platform project:
    $ lazybones create dolphin-platform-spring-boot MyProject

    The generated project contains a complete Gradle build, so you can use that to import it into your IDE that supports Gradle (like Eclipse or IntelliJ).

    To get an idea on how to proceed from here, have a look at the README of the generated project.

    If you have any questions about Dolphin Platform you can now use the “dolphin-platform” tag at stack overflow. If you are new to Dolphin Platform, find more about it on dolphin-platform.io

    Happy coding :)

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Canoo RIA Suite 2014 Update 3 available

    March 23rd, 2016

    Canoo RIASuite team is pleased to announce that Canoo RIA-Suite 2014 Update 3 (v 8.0.3) is now available for download from http://ulc.canoo.com/downloads/index.html.

    This is a minor release. It includes some bug fixes and feature requests.

    Please see the release notes http://ulc.canoo.com/external/releasenotes.html for more details.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Dolphin Platform 0.8 has been released

    February 3rd, 2016

    Yesterday, we released version 0.8 of Dolphin Platform. The version contains several bugfixes and some new features.


    The biggest new feature is the support of Java Bean Validation (JSR-303). For this feature we introduce a new module to Dolphin Platform that you can easily be added to your application dependencies:

    Once this is done you can use bean validation in the model layer. By doing so you can define your beans like this:

    As you can see the @NotNull annotation is added to the property in the bean class. By doing so you can simply validate instances of the bean by using a Validator.

    Currently not all validation annotations are supported but this is just an open todo. At the moment the following annotations are supported:

    • @AssertFalse
    • @AssertTrue
    • @DecimalMax
    • @DecimalMin
    • @NotNull
    • @Null

    For more information about the bean validation support in Dolphin Platform you should have a look at the readme.

    JavaFX bindings

    For version 0.8 we added a lot of functionality to the JavaFX binding layer. Based on this it’s now possible to simply bind a JavaFX list to an observable list of the Dolphin Platform model layer. Only one line if code is needed for this:

    Plus, we added support for converters. You can bind properties of lists of a different type to each other. This is interesting if you want to bind UI specific classes to the model layer. When using the JavaFX chart API the data model of the charts is defined by JavaFX specific classes. Since you don’t want to have this classes in the model layer that is shared between client and server you can simply define a converter and bind the model of a chart to your custom bean type. Using such a converter is as easy as a normal binding:

    Additional changes

    Next to this we added some minor features like new convenience methods in the ObservableList and fixed some bugs. A complete list of the changes can be found here.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks