Hello World in Vaadin & DukeScript

Geertjan WielengaAugust 24th, 2015Last Updated: August 24th, 2015

1 50 4 minutes read

On the face of it, Vaadin—and GWT in general—has a lot in common with DukeScript. Both are focused on providing browser-oriented solutions for Java developers and have good integration with IDEs, thanks to their native support for Maven. However, these aspects are really all that they have in common. From the programming model, to how the frameworks process the code, to how applications are deployed, Vaadin and DukeScript are totally different.

To really drive these points home, let’s start by looking at the programming models of Vaadin and DukeScript. Though the way in which you program in Java is markedly different, each has a really good motivation that makes perfect sense for the applicable target developer audience. In that sense, there is no “better” or “worse” in this story, there’s simply two different ways of enabling Java developers to have access to browser-based platforms on all kinds of devices.

In Vaadin, a major demographic in terms of developer audience is Java Swing developers who want to move their Java desktop business applications to the web and to mobile devices. For this reason, Vaadin provides a component model comparable to that of Swing. A range of GUI components, such as “Label” and “Button” are provided, as well as heaps of more complex components, including a variety of graphs and other impressive UI-related features, together with “Layouts” and “Events”, which again is reminiscent of Swing.

Here’s what a typical “Hello World” scenario looks like in Vaadin. Take note of the GUI components, the “VerticalLayout”, and the “ClickEvent”:

Hello World in Vaadin

import com.vaadin.annotations.Theme;
import com.vaadin.annotations.VaadinServletConfiguration;
import com.vaadin.annotations.Widgetset;
import com.vaadin.server.VaadinRequest;
import com.vaadin.server.VaadinServlet;
import com.vaadin.ui.Button;
import com.vaadin.ui.Button.ClickEvent;
import com.vaadin.ui.Label;
import com.vaadin.ui.UI;
import com.vaadin.ui.VerticalLayout;

@Theme("mytheme")
@Widgetset("org.hw.vaadin.MyAppWidgetset")
public class MyUI extends UI {
    @Override
    protected void init(VaadinRequest vaadinRequest) {
        final VerticalLayout layout = new VerticalLayout();
        layout.setMargin(true);
        setContent(layout);
        Button button = new Button("Click Me");
        button.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                layout.addComponent(new Label("Thank you for clicking"));
            }
        });
        layout.addComponent(button);
    }
    @WebServlet(urlPatterns = "/*", name = "MyUIServlet", asyncSupported = true)
    @VaadinServletConfiguration(ui = MyUI.class, productionMode = false)
    public static class MyUIServlet extends VaadinServlet {
    }
}

In the above, also take note of annotations used for browser-related features, i.e., themes and widget sets, as well as Java EE-related annotations, for integration with servlet containers, pointing to Vaadin being a client/sever related framework.

In contrast to Vaadin’s focus on a Swing-like development model, DukeScript has a KnockoutJS development model, which the DukeScript team considers the more advanced and modern approach. The KnockoutJS development model cleanly separates view from logic. The logic can be developed and tested before even creating the view, as discussed here. Though Vaadin applications can also be unit tested, with Vaadin you test the View (e.g., “clickButton”) while with DukeScript you test the logic (e.g., “addUser”). With DukeScript, the developer is no longer responsible for the layout and usability aspects of an application—experts can do that instead.

In the same way that Swing knowledge is helpful though not essential to use Vaadin, KnockoutJS knowledge is helpful though not essential to DukeScript usage. However, since Java developers are likely to be more familiar with Swing than with KnockoutJS, a Java developer may have to spend a little bit more time getting familiar with KnockoutJS before beginning with DukeScript.

On the other hand, the DukeScript programming model is such that the development of the frontend of the application can be delegated to frontend-specific coders, i.e., to developers who do frontend development making use of KnockoutJS. To prove this point, read this recent article on JavaCodeGeeks by Anton Epple from the DukeScript team. On yet another hand, in this kind of cleanly separated scenario, the bindings themselves can be considered part of the Java programming tasks, i.e., the Java developer would add those bindings to the markup received from the front-end developers who have put the view together.

Let’s now turn to a typical “Hello World” scenario in DukeScript. As pointed out above, the view and the business logic are split into separate files, one in HTML and the other in Java. Here’s the HTML side, which is identical to the “Hello World” scenario from KnockoutJS.com:

View of “Hello World” in DukeScript

<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>
<h2>Hello, <span data-bind="text: fullName"> </span>!</h2>

And here’s the business logic providing two-way databinding of the properties referenced above, which would normally be in JavaScript in the KnockoutJS development model, though, thanks to DukeScript, is expressed in Java:

Business logic of “Hello World” in DukeScript

import net.java.html.json.ComputedProperty;
import net.java.html.json.Model;
import net.java.html.json.Property;

@Model(className = "Data", targetId = "", properties = {
    @Property(name = "firstName", type = String.class),
    @Property(name = "lastName", type = String.class)
})
final class DataModel {
    @ComputedProperty
    static String fullName(String firstName, String lastName) {
        return firstName + " " + lastName;
    }
    private static Data ui;
    static void onPageLoad() throws Exception {
        ui = new Data();
        ui.setFirstName("Planet");
        ui.setLastName("Earth");
        ui.applyBindings();
    }
}

As with Vaadin, the DukeScript “Hello World” scenario makes use of annotations. These annotations generate a POJO with all the getters and setters that are referenced above, whenever the Java source file is saved during development.

Both these “Hello World” scenarios target the browser. How they do that, i.e., how the code above is processed and made available for usage in browsers, is the topic of the next article in this series. For the moment however, from reading this article, you should have a good idea of the differences in the programming model of these two frameworks.

By using Vaadin, you have access to a range of GUI components expressed in Java and arranged in a component tree comparable to Swing. With DukeScript, you have full access to everything that JavaScript ecosystem provides for the frontend and the entire Java ecosystem for the business logic, with a particular focus on the two-way databinding features of KnockoutJS, to connect the view to the business logic.

With thanks to Matti Tahvonen from Vaadin and Anton Epple from DukeScript who have reviewed and contributed to this article.