State of Web Components in real life app development

The collaborative Vaadin, Polymer, and Skate web platform study is almost over and we have some great initial results! After opening one month ago we’ve received over 700 responses from every kind of developer. Architects, managers, hobbyists, students, all answered our fifteen minute survey about Web Components and Progressive Web Apps.

We’re going to run the survey for one more week from the release of this blog post, so fill out the survey and share the link: .

Interesting Findings

We are planning on doing a more in depth analysis of the data, but here are three big takeaways from our survey.

Lots of people already build with Web Components

74% of respondents have used web components and at least 46% have launched a production app with web components. It’s remarkable that so many people are already building with web components. Developers cite ease of use, quicker development, and less code complexity as why they chose to build with web components.

When answering why they haven’t decided to build with web components, respondents expressed hesitation with immature standards and implementation, and many were concerned with lack of browser support. Many respondents were unhappy with web component polyfills and are waiting for better performance.

But there’s light on the horizon! All major browsers are planned to support most features of web components as early as next year.

Tables of Web Component support from

Progressive Web Apps are coming

33% of respondents have built a Progressive Web App and a full 55% are planning on building their next mobile app as a PWA. It seems that developers are committed to creating high quality web apps that work as well on mobile as they do on desktop.

On the flip side, when asked why they might build a native mobile app instead of a PWA, respondents were most concerned with performance and access to hardware such as bluetooth and accelerometer.

We believe, however, that the web platform will grow to encompass advanced use cases that currently can only be done with a native app.

Bring on the web components!

We asked respondents who use web components which element collections they use. Polymer Elements was used by 85% of respondents and our own Vaadin Elements were used by 23%.

However, 53% of respondents used in-house developed element collections, meaning that they couldn’t find the elements they needed in public collections. Now that web component specifications and libraries have matured, it’s up to developers and companies to create powerful collections of web components.

We’re excited to display all the results of this collaborative survey, so we’re going to run the survey for one more week. Keep following this blog to see our full results soon.

Click here to fill out the survey.

Vaadin Spring 1.1 is out

I’m pleased to announce that a new version of Vaadin Spring is released! The version 1.1 brings a major enhancement for Navigator and View handling, which shaves away a lot of boilerplate code from non-trivial applications that have multiple views.

Spring powered Navigator

The big new feature in Vaadin Spring 1.1 relates to using Navigator and Views in non-trivial Vaadin applications. The new version contains a SpringNavigator class that greatly simplifies the configuration of views.

There is also a new @SpringViewDisplay annotation that can be used to mark the target Vaadin component, where your views should actually be displayed. Together these two new features make it easier to create top level navigation (main layout, navigation and menu) to your non-trivial Vaadin applications.

See this example change set for how much the new API can actually simplify your Vaadin Spring code. Our Vaadin Spring documentation and Spring tutorial are also updated to showcase the new features.

A set of bugs squashed

We have also made a number of important bugfixes, prioritised by our Support customers.

One of the most relevant fixes is related to serialization of http sessions using Vaadin Spring. These fixes, which actually already landed in the 1.0.3 release, now allow using Vaadin Spring in applications which require a HA setup for hosting.

Too see the full set of changes, refer to the release notes and issues closed for milestone 1.1  in the github project.

Fully backwards compatible, upgrade now!

The new release is practically 100% backwards compatible with previous stable releases, so go ahead and upgrade your Vaadin Spring versions to 1.1.0. If you haven’t started your Spring + Vaadin project yet, see the recent Spring Boot webinar and head to, which already use the latest version!

Watch the latest Spring Boot webinar to get started

Using Vaadin Elements with Vaadin Framework

Many Vaadin Framework users have been wondering why we have started the pure client side Elements project. As discussed last month, the ultimate plan is to start using these Web Components based client side components in the client side of an upcoming version of the framework. In that version, you’ll have plain Java API for all Vaadin Elements and it will be super easy to wrap any Web Component as a Vaadin add-on.

Although the time may still not be right for a fully Web Component based client side engine, you can today already use Elements and other Web Components with Vaadin Framework. This can be done as with any other JS integration, as we have presented before, or using the Elements add-on, a helper library from our labs that makes it really easy to wrap Web Components as add-ons with a fully featured Java API.

As an example, let's see what is needed to wrap the ComboBox element as an add-on and how to share the plain Java API with others via Vaadin Directory (

Make sure you have Maven and Bower installed before following this guide.

Step 1: Create a new Vaadin add-on project

Start by creating a new add-on project using the archetype-vaadin-addon:

mvn archetype:generate -B \
   -DarchetypeGroupId=in.virit  \
   -DarchetypeArtifactId=archetype-vaadin-addon  \
   -DarchetypeRepository=  \
   -DarchetypeVersion=1.0-SNAPSHOT \
   -DgroupId=org.vaadin.elements \
   -DartifactId=combobox-element \

Optionally, remove the example and test code (except the Server class which is used to run the test application).

Step 2: Add the required dependencies

Add the Elements add-on dependency in the pom.xml file:


Download the vaadin-combo-box HTML element by running the following command from the src/main/resources/VAADIN directory (create it, if it doesn’t exist):

    cd src/main/resources/VAADIN
    bower install --save vaadin-combo-box

Alternatively, you can add a .bowerrc file to avoid changing to the VAADIN directory when you need to install multiple elements, for example.

Step 3: Extend the Element interface

Define a new ComboBoxElement interface that extends Element and imports the vaadin-combo-box HTML element:

package org.vaadin.elements;

public interface ComboBoxElement extends Element {

    static ComboBoxElement create() {
        return Elements.create(ComboBoxElement.class);

    void setLabel(String label);

    void setItems(String items);

    void setValue(String value);

    String getValue();

You don’t have to implement this interface. The Elements add-on will provide an implementation at runtime and will match the setters and getters with the corresponding attributes of the HTML element.

Step 4: Wrap the element in a Vaadin component

Implement a new ComboBoxComponent class to encapsulate the low-level ComboBoxElement class:

package org.vaadin.elements;

import elemental.json.JsonArray;
import elemental.json.impl.JreJsonFactory;

public class ComboBoxComponent extends AbstractElementComponent {

    public static interface ValueChangeListener {
        void valueChange(String option);

    private ComboBoxElement element;

    public ComboBoxComponent(String label, String... options) {
        element = ComboBoxElement.create();
        element.bindAttribute("value", "change");

        if (options != null) {
            JsonArray array = new JreJsonFactory().createArray();

            for (int i = 0; i < options.length; i++) {
                array.set(i, options[i]);

        Root root = ElementIntegration.getRoot(this);

    public String getValue() {
        return element.getValue();

    public void setValue(String value) {

    public void addValueChangeListener(ValueChangeListener listener) {
                args -> listener.valueChange(getValue()));

This class uses the Elements add-on to implement a Vaadin UI component that you can add into any component container, such as VerticalLayout or Panel. To make it simple for this guide, we are extending AbstractElementComponent, however, you can extend any Vaadin component that suits your specific use case (see for example the DatePicker add-on).

Step 5: Implement a test UI

Implement a test UI inside the test directory:

package org.vaadin.elements;

import com.vaadin.ui.Component;
import com.vaadin.ui.Notification;
import org.vaadin.addonhelpers.AbstractTest;

public class BasicComboBoxComponentUsageUI extends AbstractTest {

    public Component getTestComponent() {
        ComboBoxComponent comboBox =
            new ComboBoxComponent("Select an option",
                "Option 1", "Option 2", "Option 3");

        comboBox.setValue("Option 2");
            value ->;

        return comboBox;

The Maven archetype we used includes a set of utilities to make the development of add-ons easier. One of these utilities is a Server that creates a UI that discovers instances of type AbstractTest (which in turn, extends UI) and shows them on a list allowing you to select the AbstractTest you want to try.

Please note that at the time of writing this not all browsers natively support the technologies that enable Web Components. However, it’s possible to include a set of pollyfills by including the webcomponents.js file via the @JavaScript annotation.

Step 6: Run the test application

Run the Server.main() method from your IDE or using Maven:

    mvn package exec:java -Dexec.mainClass="org.vaadin.elements.uiserver.Server" -Dexec.classpathScope=test

Point your browser to http://localhost:9998 and click the BasicComboBoxComponentUsageUI link.

The following is a screenshot of the application:

Screen Shot 2016-10-19 at 15.26.31.png

Step 7: Publishing the component as an add-on

To publish the add-on at, follow the instructions in the generated file.

The example add-on I implemented in this exercise is already available via Directory. It probably makes no sense to use this add-on instead of the ComboBox component from the core, but I hope it inspires you to wrap other Web Components with a plain Java API!

Check out the full example on GitHub