We are Vaadin - Sebastian from the Vaadin Berlin office

Sebastian works at the Vaadin office in Berlin and is currently occupied with some upcoming new products and proof of concepting them. He joined Vaadin in the beginning of March, so only 5 months in the company and already working in Vaadin projects at full speed.

Q. What did you do before Vaadin? 
I worked as an IT-consultant in Germany for a couple of years and mostly did projects in the area of financial services. Before that I finished my studies of Computer Science in Berlin and tried to spend as much time as possible abroad and face intercultural challenges. 

Q. Why did you decide to join Vaadin?
During my studies I came in touch with Vaadin for a small web-application and I was very excited about the technology, with how little effort I could create a proper and good looking website, and the exchange in the community. When Vaadin decided to open an office in Berlin, I instantly wanted to join the Vaadin team and work with the newest technology trends at the market.

Q. What’s it like working in Vaadin’s Berlin office with Finnish and US colleagues?
There are challenges, we are in different time zones and locations. However, we overcome this with using modern technologies to communicate and share ideas. For example, to create technical concepts or plan projects, we are using different web applications that anyone can access. This is the perfect basis to provide an overview or discuss ideas over the distance. In this way, we are exchanging and sharing a lot of ideas with our colleagues every day, and the Vaadin team members are travelling between offices regularly which is great in my opinion.

Q. What has been the most surprising thing?
How free I actually am in choosing my way of working - we have been given the freedom to use the best possible tool to succeed in our job. That is really cool - there is trust among colleagues and the team. The other point that I am surprised by is that for the most part Vaadin people fit very well together - so it does not matter in which location, nationality or gender you are.

Q. What makes this a great workplace?
The free choice of hardware and equipment, new projects are offered by asking us ‘what would you like to do ?’, and our own strengths are used in the best possible way. I have the possibility to influence on my own job. That is great!

Q. What do you do in your freetime and does it help your work somehow?
I do a lot of sports, e.g. cross-fit and badminton with colleagues, since we sit a lot in our work, the software business is like that by nature. In addition, I love to travel - it is really good to get different points of view on cultures and also to relax. Travel experiences help when we have diverse customers from diverse/different countries - it helps to communicate and understand them better.

Q. What would you say is the #1 reason for working at Vaadin?
Because of the amazing people! It is really the mostly the great team behind the technology, we are all for all (not for one), super team work is the key success factor. The environment is open for discussion and opinions - we share our common challenges and try to solve them together, really.


Adventures in SEO

TL;DR: Vaadin was hardly SEO-friendly in the past. Not anymore, with the new Volga library.

Bookmarking pages

Bookmarking is as old as www itself. Being able to save an URL is part of the ADN of websites. Regarding web apps, this is somewhat different. For example, in an e-commerce webapp, while it does make sense to bookmark a specific product, bookmarking a specific step of the checkout process does not.

Following the shop example, here’s what happens in a traditional servlet-based context:

  1. A servlet is mapped on a specific subcontext such as /product/*
  2. When the URL /product/really-cool-product is called, the doGet() method of that servlet is called
  3. The method parses the URL to read the really-cool-product part - which should be an unique key for the product
  4. It delegates to a whole chain of components that loads the product from the datastore
  5. It forwards to a JSP along with the relevant product data
  6. This JSP generates the HTML

Single-Page Applications

Come SPAs. By definition, they serve all content under the same URL. This makes bookmarking specific pages of the application impossible because there are no pages per se. In general, SPAs handle this problem with fragment identifiers. The above URL becomes /product#really-cool-product, problem solved. In Vaadin, this directly translate to usage of the Page.getCurrent().setUriFragment() method or of the Navigator API.

Unfortunately, this doesn’t work at all with the crawling part of SEO. Fragments are not discriminatory parts of an URL: #really-cool-product and #another-cool-product do point to the same URL so bots such as Google Bot won’t crawl both.

The fragment identifier functions differently than the rest of the URI: namely, its processing is exclusively client-side with no participation from the web server. 
-- Wikipedia


For a while Google recommended to use special “hashbang” style URLs (#!my-indexable-view), like what Navigator in Vaadin uses, and specially served SEO material for those views, but this was a tricky workaround and the approach is now deprecated by Google as well.

Distinct URLs for SPAs

Back to square one, both /product/really-cool-product and /product/another-cool-product paths are required. This problem is not unique to Vaadin, but common to all server- and client-side SPA frameworks. What is required is:

  1. To have the client change the browser’s URL without full page reload
  2. To have the server handle paths

In JavaScript, the answer is to use the History API. I assume everyone is familiar with the following snippet:


This is however absolutely not standard. This should be replaced by the following:


The history object implements the History API. It’s supported by all modern browsers. In particular, the API makes it possible to add entries in the browser history via thepushState() method, without actually doing full page loads.

Suppose executes the following JavaScript:
var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");
This will cause the URL bar to display, but won't cause the browser to load bar.html or even check that bar.html exists.
--Mozilla Developer Network

Note that Vaadin Directory contains the History wrapper library around the client-side API. It provides a way to manage the history object from server-side Vaadin code.

On the server-side, paths also need to be handled. In Vaadin apps, full URLs are accessible in UI.init() methods, from servlets or from e.g. BootstrapListeners. The History add-on also supports the Navigator API and View objects with full paths without hashbang-style URLs.

Beyond distinct URLs

Distinct URLs is only the emerged part of the iceberg regarding SEO.

One wants to have dedicated meta headers for each dedicated URL, such as <title> and <meta name="description">. Even further, social medias have their own dedicated meta headers, e.g.:

Volga, the SEO-friendly Vaadin library

Implementing the steps above from scratch in your Vaadin project is definitely not trivial. Rejoice, for comes Volga, a ready-to-use library that handles the brunt of things for you.

To use it, just add this snippet to your POM:


Important part of the API include:

Holds a set of metadata headers
Set the VolgaDetails for the root path and provides bindings between a path and other VolgaDetails objects. This way, each specific path can be set their own VolgaDetails.
Holds the previously defined mappings
Handles the initial configuration
Fills page metadata headers from a VolgaDetails object

For more details, please check this example project on Github. It's deployed online and here are results shown on Google search that proves that it works.


Demo application as seen on Google Search

This works for Twitter as well:

Twitter card for main view Twitter card for second

Miscellaneous finishing touches

There are also a couple of other tricks to consider to help bots crawl Vaadin apps.

  • Use a robots.txt file
  • Use a sitemap.xml
  • Use basic links to navigate between views (see PushStateLink in History)
  • Use well-formed HTML, e.g. use proper <h1> elements instead of just styling headers bigger (see Header and RichText in Viritin)

Note, that GWT is currently failing to serve anything relevant for GoogleBot by default. A patch is available in Volga but it will be fixed in Vaadin itself soon

Don’t wait and make relevant parts of your app SEO-friendly with Volga now!

Demystifying widget set cloud compilation

The Vaadin Framework 7.7 release brought major improvements for widgetset handling in general. Probably the most interesting part in the new release is the possibility to delegate the time consuming widgetset compilation to a cloud service, which can also host your widgetset. These are big changes that raise a lot of questions among Vaadin developers. How does it actually work? Is it secure? Can I trust this service in production? Let’s demystify the cloud compilation service.

We just held a webinar on the same topic, but as this is such an important renewal, let’s go through the same things here, as well.

What is the purpose of a widget set in general?

Each Vaadin UI component has a server side class, an API that you actually use in your application, and a client side implementation that takes care of the rendering and state synchronisation in the browser. Widgetsets in Vaadin are GWT modules which combine client side component implementations from the core and from various add-ons to a compact client side engine needed by your application. GWT compilation makes both Java to JavaScript transpiling and a vast amount of optimizations for the code, which makes the GWT compilation part a rather expensive process in terms of CPU and memory usage.

What gets sent to the cloud and back?

On each compilation, the actual output of a GWT compilation is practically identical, unless the Vaadin version or some of the client side extensions have changed. This is also what the new cloud service needs to know to compile the widgetset for you: the Vaadin Framework version and the list of add-ons (and their versions) you use in your project.

Cloud widget set modes.

Choose the mode

You can choose the way your widgetset gets served on compile time by setting the parameter in your pom.xml plugin configuration:

                 <!-- Widget set compilation. 
                      Possible values are: local, cdn, fetch -->

    <!-- Other build plugin configurations -->

or if you prefer, just simply setting the following project property in the beginning of pom.xml:

    <!-- Widget set compilation. Possible values are: local, cdn, fetch -->

    <!-- Your other project properties -->

By default everything still happens locally as before, but when you use “cdn” or “fetch” options with the new vaadin-maven-plugin, the plugin gathers the version of Vaadin Framework and all your client side add-ons and sends this information to the cloud service, nothing more. No source code or details of other custom libraries is needed to cloud compute a widgetset suitable for your application.

Based on these details, the cloud service calculates a hash that works as a key to your widgetset. In “cdn” mode the service just returns a URL to a hosted version of your widgetset and always returns practically immediately. This way the rest of your build can continue while your widgetset gets compiled by the cloud service. If the widgetset is not yet ready when you, for example, have deployed your application for testing, you’ll get a notification in your browser that states the compilation may take a bit of time.

In the “fetch” mode the cloud service returns the compiled widgetset in the response and the maven plugin saves that to your project’s generated sources.

“Avoiding” GWT compilation

Widgetset compilation is often a major part of the full build of your project. Some Vaadin users have optimized this by creating a separate module for the widgetset, which is then used by the main software project. A new version of the client side module is compiled whenever any of the Vaadin add-ons or the Vaadin Framework version itself is updated. This way you can keep a full build of the main project super fast, even with “mvn clean install”.

The new cloud service uses the same kind of approach to “speed up” the compilation. There are lots of Vaadin applications out there which only use e.g. the core framework and Vaadin Charts. The cloud service compiles a unique widgetset just once and serves the cached version for other users. The very same client side module may now be used by you as well as your teammate and even your closest competitor. Caching works for both “cdn” and “fetch” modes.

Can I use it in production?

Well, that depends. I would certainly use it for my non critical hobby apps, but I wouldn’t suggest all parts of it to our customers.

The cloud service is hosted by Vaadin Ltd, the company which also contributes most to the open source project itself. So it is hosted by a credible company and it doesn’t cost you anything, but on the other hand, there is no guarantee that it will be always up. If the service goes down, your users cannot access your application in “cdn” mode and also, if just your own network connection is down, it might halt your development. Luckily you most often just need to change one parameter and you are back to traditional local compilation.

From security point of view, no source code is shared with the service, but you expose the Vaadin version and add-on version you are using to the service, both in “cdn” and “fetch” options. Also you’d probably like to host all resources from your own server if you are building really mission critical applications, so a no-go for the “cdn” option in that case.

The cdn hosting option supports TLS connections and is fronted by a strong CDN service for fast access from all over the world, but it is still a third party service increasing risks to your application’s stability.

So, we urge you to try it during development, but for production usage, it is still better to fall back to hosting everything yourself.

Other limitations?

Yes, there are. There are currently two major limitations. The first one is that no project specific client side customizations are supported. Currently all client side add-ons (and their transitive dependencies) you use must be available via Directory or from Maven central.

Also, you cannot provide a custom GWT module aka the YourApplicationWidgetset.gwt.xml file. That file is automatically generated by the cloud service and if you’d like, for example, to use a deferred binding rule to provide a custom client side implementation for certain component, it won’t work with the cloud service. The same thing if you’d like to use the widgetset optimization trick, it just doesn’t work with the current version of the cloud service.


Even though cloud compilation doesn’t fit each and every Vaadin application, because of security, stability and flexibility concerns, we believe it is a great step forward in developer productivity. For most, Vaadin development becomes both simpler and faster.

We are also keen on your feedback and enhancement ideas. We'll be actively monitoring your questions of forum or you can privately send us feedback with the form below!

Try Vaadin 7.7 today!

Feedback form: