Saturday, November 25, 2017

A first look at Vaadin Flow / Vaadin 10

Only recently the guys from Vaadin published the developer preview of thier upcoming Vaadin 10 release. As I have been teaching Vaadin 8 I wanted to catch up and see what Vaadin 10 will bring.

There is a big change in that Vaadin turns away from using GWT for its client side Components. It has a whole new direction in that client side Components are now implemented using Polymer and WebComponents. Let's say it as it is - this could be a game changer.

So I went for the starter apps provided on the Vaadin Website and tried the Hello World Examples. There are no archteypes yet, at least there is a TODO there. The first thing one notices is, that we get quite a bunch of dependencies, Vaadin has been split up into mutliple modules, and we see a lot of webjars for the components.

This is where my confusion started: I have all the components as webjars, but they are listed once again in a package.json to be resolved by bower. The documentation on this is confusing, you can go with bower only, you need it at least for the moment for the production build, and it says that in the future there may be a way with webjars only. That I have every component twice really gave me a puzzler.

Then I tried to take a dive into the existing documentation, and for now I can say that I understood that there are many ways of using Vaadin 10.


  • One can work as we used to to using Vaadin Components. The way navigation is handled has changed fundamentally, but the principles of using Vaadin in a way like we are used from Desktop UI Frameworks, with Java Components organized in a Tree can be done as before.
  • There is a new low-level Elements API that lets us manipulate the Dom on the server side. Unfortunately this is the first chapter in the docs. Maybe this is the last thing I want to do.
  • It is really very easy to integrate any existing Polymer Component to be used as a server side component. Indeed this is so easy that using the built in Vaadin Components is completely optional.
  • Probably the most exciting stuff to me is the PolymerTemplate class. One can create a HTML Template with Polymer (I managed to to this without digging any deeper into polymer). Vaadin Flow Provides a mechanism to synchronize a so called TemplateModel between Server and Client. The Model is basically described as an interface or pojo on the server side, Flow sync it to the client and the values can be bound on the client side into the Polymer template. Not to forget that Events on the client can be easily bound the methods on the server by simply adding an annotation.

To sum it up:

  • The state of the developer release might be a little confusing. Especially the webjars/bower dependencies. But there are signs that this may change until the final release. The docs are in an early state put they are already quite helpful.
  • If we want to, we can work with Vaadin Components as we did before - The biggest change may be the new routing mechanism.
  • We get a plethora of webcomponents that we can use with Vaadin easily. At Devoxx Belgium one of tha Vaadin guys told me that there will be even a generator to create the server-side Java classes,
  • Using templates and polymer, it's no big deal anymore to move stuff to the client side if desired.
  • I'd really like to see the Binding API work alongside with the TemplateModel

One thing that I wished for, but found no solution: Writing the client side in Kotlin/JS. Hopefully some genius will create a Kotlin/Polymer Binding. Up to now you have to use ES6 Javascript Syntax.

2 comments:

Juha Seppänen said...

"I'd really like to see the Binding API work alongside with the TemplateModel"

How do you envision the Binder and TemplateModel to work alongside?

Thomas Kratz said...

I don't think it would be easy. The properties could be exposed as values and fire events. Just a thought.