CUBA Studio — How we use Vaadin for our Web Development Tool

CUBA Platform is a fairly new and rapidly growing Java framework for efficient enterprise application development. A significant part of its success can be associated with its own development tool - CUBA Studio, which is Vaadin-faced to the users.

Often, to employ one or another framework, you have to leaf through hundreds of pages before you even get started with the first line in your source code. In order to minimize the barriers to entry for CUBA Platform, we have developed our own framework-aware development tool for rapid business application development - CUBA Studio. CUBA Studio provides a convenient and intuitive graphical interface to any feature of the platform, where you can create your “Hello world” CUBA application in minutes. The studio manages many common aspects of enterprise application development: data model creation, visual layout design, source code scaffolding and so on.

When we started the development of CUBA Studio, we already had built up a large quantity of experience with Vaadin in CUBA Platform, because the generic UI of the platform is also built over this framework. So, why did we choose Vaadin? In this post I will highlight the most valuable features and interesting use cases.

Pure Java for Complex UI

Since CUBA Studio is a UI-oriented application with a big codebase, it requires good readability and maintainability of its source code. With Vaadin, we can use Java for the entire application. Vaadin makes it possible to use all existing Java libraries from our UI code directly. In addition, Java enables us to inherit and extend the functionality of the framework and third party add-ons. This ability to customize and change the standard behaviour of the components brings flexibility that is fundamental to CUBA Studio.

Thanks to the API of Vaadin, we can code the UI layout simply and quickly, like we use Swing or C# WinForms.

Let’s see how we can create a dialog window of CUBA Studio with Vaadin:

final Window newProjectWindow = new Window();
newProjectWindow.setCaption("New project");
newProjectWindow.setWidth(400, Unit.PIXELS);

VerticalLayout content = new VerticalLayout();

// add grid with properties of a new project
GridLayout grid = new GridLayout(2, 2);
grid.setColumnExpandRatio(1, 1);
grid.setWidth(100, Unit.PERCENTAGE);
Label nameLabel = new Label("Name");

// add input controls
TextField nameField = new TextField();
nameField.setWidth(100, Unit.PERCENTAGE);
Label versionLabel = new Label("Platform version");

ComboBox versionBox = new ComboBox();
versionBox.setWidth(100, Unit.PERCENTAGE);

// add OK and Cancel buttons
HorizontalLayout buttons = new HorizontalLayout();
buttons.addComponent(new Button("OK"));
buttons.addComponent(new Button("Cancel"));


// show window

Let’s have a look at the result:

This code is very easy to read and modify, because of its homogeneous nature (pure Java) and it does not require HTML markup or CSS styling for the layout of the UI components on a screen.

Have a look at the screen editor in CUBA Studio to see how complex screens can be built using Vaadin. A rich set of UI components within the framework enables us to organize a workspace for our development tool, similar to traditional desktop tools. 

Screen properties

WYSIWYG Screen editor

Wide Community and Rich Set of Addons

Our choice of Vaadin was also dictated by the large community and the wide range of third party add-on visual components. You can find many useful components using Vaadin Addons Directory. Add-ons are easy to add to your Vaadin project, as Maven dependencies, or as a simple jar library. We use a couple of Vaadin add-ons in CUBA Studio. For example, CUBA Studio enables you to scaffold and code sources for entities and screens and services right from your web browser with syntax highlighting. This feature is provided by a Vaadin third party addon - AceEditor

One more addon we have used in CUBA Studio is DragDropLayouts. The Drag-And-Drop approach is used for the WYSIWIG Screen designer, as you can see in the picture below.

Simple Client-Server-Client Communication Using AJAX

Modern web applications should be responsive, fast and user-friendly. Users expect a good reaction on interactions from any IDE. This is very difficult to achieve in a web tool due to the network nature, but we can use PUSH technologies for communication with a server to increase the performance of a web UI. Vaadin enables us to use the WebSocket protocol to organize a client-server communication in case of long background processing. We use this approach a lot, for example, to index a project on Studio startup or during a web server start.

To illustrate the way of how it is used in CUBA Studio, let’s implement a simple handler for the OK button of our “New project” dialog, which executes a fake long operation in the background thread and shows a notification to a user once the long operation is completed:

buttons.addComponent(new Button("OK", new Button.ClickListener() {
   public void buttonClick(Button.ClickEvent event) {
       // you can use ../valo/shared/img/spinner.gif
       newProjectWindow.setIcon(new ThemeResource("img/spinner.gif"));
       newProjectWindow.setCaption("Creating new project ...");
       final UI ui = UI.getCurrent();
       Thread projectCreateThread = new Thread(new Runnable() {
           public void run() {
               try {
                   // just emulate long project creation
               } catch (InterruptedException ignored) {}
               ui.access(new Runnable() {
                   public void run() {
             "New project has been created", Type.TRAY_NOTIFICATION);

So, you don’t need to write JavaScript code and support all the tricks of different browsers. Read more about PUSH notifications in the Book of Vaadin.


To sum up, Vaadin became a very good fit for our product. I could go on and on telling you about the features you can get with this framework, but let me just say that “It’s better to see something once, than to hear about it a hundred times” and I invite you all to visit a live demo of CUBA Studio. The demo version is available in read only mode. To see the full power of it, you can always download it from our website.

Try CUBA Studio now


Community Spotlight - January 2016

Spotlight, featured image

In the end of last year, our Community Spotlights were quite focused on new add-ons published to Directory. It has been really active on that front lately as well, but this time, let’s concentrate on some of the most interesting articles and examples you have recently created.

MVP in Vaadin Spring applications

For the German speaking audience, there is again some quality content available. Dr. Stefan Reisner shares his ideas of how to use MVP pattern with Spring based Vaadin applications.

Vaadin Spreadsheet to replace Excel on your workstations?

Michael Kanis shares his experiences of using Vaadin Spreadsheet. This article is also in German, but it traslates well with Chrome to English. The interesting part in his solution is that he actually packages the whole Vaadin app as an executable JAR file for local usage. This way can replace an old Excel based solution directly with Vaadin Spreadsheet. Naturally this kind of solution also has a lot of potential to add more advanced features in the future using a real development environment.

Petstore example using Spring Boot and Vaadin

Do you remember the iconic Java EE Petstore reference application and its Spring counterpart? Igor Baiborodine has done a super cool re-implementation of Petstore with a Spring based backend and modern Vaadin UI. In case somebody is asking for a larger Vaadin reference application, this is definitely my answer in the future.

Using jOOQ from Vaadin apps

Peter Kudela has set up an example that uses jOOQ for database access and a Vaadin app that uses the jOOQ service to access the data. Lukas Eder, the founder of the jOOQ project, already gave some insights for the database integration, but if you like both jOOQ and Vaadin, join Peter to develop the example further!

More Vaadin in Kotlin stuff

A Vaadin user, book author and a well known Vaadin advocate, Nicolas Fränkel, got recently interested in an alternative JVM language called Kotlin. Last year we already  discussed about Vaadlin, a tool by Sergei Egorov, to help Vaadin usage from Kotlin applications. A recent article by Nicolas discusses just the usage of raw Kotlin, but integrates it with his old favourites, Spring Boot and Vaadin.  

Tips for Scala users

Volkan Yazici shares some tips for another alternative JVM language - Scala. His article Scala Shortcuts for Vaadin Development contains lots of practical code snippets that might be handy for Scala developers building their UI with Vaadin.

Web Components in production use – are we there yet?

Web Components are here

A lot of progress has been made since the introduction of the Web Components back in 2011. All major browsers have started implementation of the technologies needed to run web components natively. While browser vendors are still working on native implementations, libraries have been able to use a polyfill to make web components available to developers already.

But what is the status of Web Components for actual production use in business applications? In this post, I’ll be taking a look at the support for Web Components in browsers and their adaptation by companies. But before we get to that, let’s take a quick refresher on what Web Components are and why we would want to use them in the first place.

The promise of Web Components

Web Components aim to change the way we build web applications by allowing developers to extend the HTML vocabulary by creating their own reusable HTML elements. This seemingly simple addition means that developers can build their software out of higher level components.

Component based UI libraries have been the standard way of building complex native applications for years, and many modern web frameworks like Angular and Vaadin give us the ability to compose our UI out of reusable blocks. The big difference between these approaches and Web Components is that Web Components bring the componentization to a DOM level so that the custom elements can be used with any framework just like any standard HTML element.

One of the great advantages of Web Components is that they allow us to build on other’s work instead of reinventing the wheel. Most software use a fairly standardized set of UI controls – components like data tables, date pickers, input fields etc. By using an existing component for your software you are not only saving the time that it would take you to build it in the first place, but you also don’t need to spend time maintaining it in the future. Instead, you get the benefits of more people contributing bug fixes and performance improvements to the same component - resulting in a better component for all users.

For a more in-depth look at the history of Web Component and the problems they hope to solve, I suggest reading this great blog post on the Microsoft Edge Blog.

When we talk about Web Components, we are really talking about four separate W3C standards that together give us the tools we need to build our own components: Custom Elements, Templates, HTML Imports and Shadow DOM.

The Custom Element standard defines a way for us to define new element types in the browser DOM. This allows us to give our components a meaningful name that allows developers to use the component like any other HTML element. For instance, the Vaadin Grid defines a <vaadin-grid> element.

HTML Imports are a way of including HTML documents in other documents. This enables us to reuse the components as we can include them on any page without having to copy-paste the HTML.

Templates allow us to define inert HTML subtrees that can be stamped into the DOM. Being inert means that we can define the HTML without inserting it into the DOM or running it. As an example, this allows us to import <vaadin-grid> into our document without it showing up before we actually use it by inserting a <vaadin-grid> tag into our HTML.

Shadow DOM is the core of the Web Components standards. Shadow DOM allows us to encapsulate our element implementation into a separate DOM tree in order to shield it form the surrounding document, and conversely shielding the host document from changes introduced by the component. A good example of why we want to do this is CSS styling. We do not want styles from a Web Component to affect the parent page, and conversely, we don’t want the parent page to break the component. The Shadow DOM spec gives us the tools to control how we want the trees to interact with each other.

State of browser support

As I mentioned earlier on, all browser vendors are working on introducing native support for Web Components. What’s even better is that a lot of collaboration is happening between the vendors, with members from each participating in the specification process.

Chrome is the current gold standard for Web Component support, largely because of Google’s strong role in pushing for the standards. All four parts of the Web Components standards have native support in Chrome and can be used without polyfills.

Firefox ships with an implementation for Templates and allows you to turn on Shadow DOM and Custom Elements with a development flag. The only remaining piece, HTML Imports, has been put on hold as they feel that there is too much overlap between ES6 Module Loading and HTML Imports and want to see how this plays out. Regardless of this, Wilson Page from Mozilla concluded in a June blog post that “we’re optimistic the end is near. All major vendors are on board, enthusiastic, and investing significant time to help resolve the remaining issues.”

Safari (WebKit) ships with template support and as of recently Shadow DOM support in nightlies. There is also a prototype implementation of Custom Elements, but like Mozilla, the WebKit team believes that ES6 modules should be the basis for importing templates and is therefore not actively working on supporting them yet.

Microsoft recently shipped HTML Template support in Edge 13. In a blog post, they indicated that they are working on implementing all of the Web Component standards and are collaborating with the other vendors in finalizing the specification work.


As native browser support is not quite there yet even in the most recent browser versions, any production use will still need to rely on the Web Components Polyfill in order to support most browsers. With the polyfill, Web Components can be used in all the latest evergreen web browsers as well as Internet Explorer 11. As Microsoft ended support for older versions of IE in January the polyfill will allow you to target all actively supported web browsers out there.

As more browsers are adding support for Web Components, you should use feature detection to determine whether or not the polyfill is needed, so users on browsers with native support can get a faster experience.


The Web Component APIs offer fairly low level programmatic APIs, so several libraries have been created to ease the development of new Web Components: X-Tag, Polymer and Bosonic. All the libraries offer helpers and syntax sugar to cut down boilerplate code and make creating new components easier. They all use the same Web Components polyfill as their base.

Both Polymer and Bosonic also offer a library of ready made Web Components in addition to the helper APIs. Fortunately, as a consumer of Web Components you don’t need to worry about what libraries have been used for creating components. As they are all based on the Web Components standards, you can mix and match components as you please.

Out of the three libraries, Polymer has been most widely adopted. The Vaadin Elements web component library is based on Polymer.

Web Component adaptation

Web Components have been taken into production use by several big companies such as Google, GitHub, Comcast, Salesforce and General Electric. Some of the more high profile sites using Web Components are Youtube Gaming, Google Patents, Google Music and GitHub.

According to the Chrome Dev Summit Keynote by Taylor Savage, there were already over 1,000,000 sites using Polymer in November 2015. So even though Web Components are still a new and evolving technology, there are already a lot of people and companies using them in the wild.

Should you build your app with Web Components?

Now that we’ve seen that Web Components are already in production use by some of the biggest companies in the world and that the Web Component polyfill will allow us to support all modern browsers, the question that remains to be answered – how do you get started?

Many people struggle with understanding how Web Components should be used. Should individual Web Components be used to extend existing front end frameworks, or should you build your entire application out of Web Components?

The creators of Bosonic explain that “Web Components enable the creation of UI atoms as HTML elements, atoms that you can include into your components templates, powered by Angular, Ember, React or whatever”. Likewise, Kevin Schaaf from the Polymer team explained that “Polymer’s primary mission is to help you build custom elements – full stop”. However, he continues to explain that by leveraging the DOM as your framework, you are able to build full applications with nothing but Web Components.

This means that you can use Web Components as much or as little as you want in your application. You can decide to only improve one static table on your site by wrapping it in a <vaadin-grid> or introduce a “time ago” tag like GitHub. But there’s also nothing preventing you from building a full blown application with nothing but Web Components like we did in our Expense Manager Web Components demo application – the choice is yours.

Get started with the Vaadin Elements Web Component library