Discussing Vaadin 7 with Joonas Lehtinen - Part 2

Joonas Lehtinen

Joonas Lehtinen


Google Web Toolkit is now in Vaadin 7, what role does it play?

We've actually been using GWT for 5 years now in really crucial parts of Vaadin and we've been using it mostly as as a rendering layer thus far. So we have been using GWT under the hood ourselves and also as a tool for the widget authors to build their own Vaadin widgets. But now in Vaadin 7, we're doing something different. We've merged the whole Google Web Toolkit inside Vaadin, and packaged that directly within the Vaadin product.

That has two different implications. The first one is that there are no extra dependencies at all in Vaadin. It doesn't depend upon anything external from Google Web Toolkit – everything is in one bundle. That means we can fix bugs and we can deliver it as a unified solution. Another implication for us is that while now Vaadin has been purely a server side framework, now there is a really really powerful client side model as well built into Vaadin. All of the pieces you have in GWT, all of them are built into Vaadin 7.

So it opens up some new concepts, taking you to a new level?

We see that there are three different abstraction levels we can work in, in Vaadin. The traditional one, and I'd say the most efficient one is writing Java code on the server side. That's composing your UI out of components, but now when we also have GWT built in, you can also do client side UIs. You can write Java, compile that into JavaScript and run that on the client side. That's really powerful in some cases, when you want to customise more or you want lower the latency or want to build offline applications. The third abstraction level is through pure GWT and write in JavaScript for the HTML5 layer. Where the power lies is that you have to go through these layers if you really want to. Most of the time you can keep on the highest abstraction level, you don't have to touch these underlying layers if you don't need to.

Can you explain how other JVM languages are supported in Vaadin?

All the Vaadin components, that's just plain Java objects (POJOs). Anything you can do in Java, you can do in Vaadin. So therefore, you can basically use any JVM language to build Vaadin UIs. We're starting to see people use Groovy and Scala and Clojure and those kind of languages for building Vaadin UIs.

Our team is more and more using especially Scala. It's actually really nice to see that there are the same benefits that we are looking after. We want to minimise the line of code you have to write in order to build good UIs in Vaadin. Scala is really compact and also kind of minimises the lines of code you have to write to build any application. When you combine these two things together, you actually have an efficient way to write your Vaadin interface. 

How important has HTML become to regular Java developer, or is it going to get even bigger?

In my opinion, everything is running on top of HTML5. The technology itself has become so powerful that there really is little need to build any client side applications anymore. There's little need to build let’s say, Java Swing application or anything like that. The only place where client side applications are still living is in the mobile space with iOS and Android.

How does Vaadin cater for mobile development in that case? 

Everything you build in Vaadin is ready for modern mobile browsers. They run directly on iOS and Android devices but we also wanted to set up native-looking widgets. That's a library called Vaadin TouchKit. It just adds native-looking widgets to Vaadin. You can totally leave it out if you're happy with the widgets built into the core Vaadin.

Back in June, Vaadin became a part of the Steering Committee behind GWT. What was the reasoning behind wanting to be part of it, and what's happened since then?

We started hearing questions from the community what's happening with GWT? If it's not replacing GWT, what will happen for Vaadin is that the GWT would somehow go away. We had to answer those questions somehow. Either we would be downplaying the role of the GWT in Vaadin and maybe preparing to move from GWT to some other client side technology. Or somehow take more responsibility over making sure that GWT thrives in the future.

We chose the latter option. It actually was a good thing to see at the time Google wanted to get more players on the same field. GWT has been developed like in a quite, I cannot say closed manner, but completely within Google. They wanted to open doors to other contributors as well. That was a really good timing for us that we could be one of the companies to sign up to make GWT stronger in the future. 

You helped produce the Future GWT Report. How important was the insight you gained from this?

We basically wanted to see where we were with GWT. We asked 1,350 or so people questions on how they're using it and what they want to see in the future in GWT. We were totally overwhelmed by the responses.

I think it really shows that the use of GWT is really strong at the moment. It's used in enterprises, by internal applications most of the time, so it's not as visible as some other consumer-facing web technologies. It's used by huge projects with huge budgets. These projects aren't going away. That kind of cemented our view that we should be investing in GWT and building our business more and more on top of GWT.

The survey showed that there was still a huge enterprise backing for it and I guess you felt the same way?

You could have seen Vaadin as competing with GWT in the past. It's like our commendation that you should be building things on the client side or on the server side, whether you should be using GWT or Vaadin. And now by merging these two things, we hope that people don't have to make the choice anymore. They can use Vaadin and if they see a need for building client side applications, this is also possible within Vaadin.

 If there was a most important finding in GWT Report, what was it?

The magnitude of the news of GWT ['s relevance] is the most important for me. The most surprising one for me is that it's actually quite Euro-centric. I was expecting the US to be No.1 in the report. There's quite a few more European users and that was surprising for me.

Vaadin 7 hit a few delays – why did this happen?

Vaadin 6 was really successful for us in 2009 and we built eight minor releases on top of Vaadin 6. It was like two or three minor releases each year and we built for a long time on that adding features. At the same time, we kept all the backwards compatibility in the APIs and we started rolling a huge backload of things that we would like to change in Vaadin if we really could do some changes in the API.

That backlog had been growing for years, and at the same time, the internals of Vaadin had been getting older and older. Some of the internals are still exactly the same that I wrote in 2002, so they have a long history behind them.

We had a huge list of wishes that we wanted to implement in Vaadin 7, and when we started 18 months ago, we had so many things that we really wanted to fit on the list. We ended up kind of building too long a list for ourselves. We projected that it would a take a year's development to implement those features, and we really failed in that. We both dropped some really important features from the list and postponed those to Vaadin 7.1 and at the same time also, we slipped some forward in other milestones. It took a longer period to implement those than we anticipated.

But also the part of the problem was whether we wanted to deliver it at JavaOne or if that would fail, Devoxx, and we actually failed with both. But now it looks really solid for release on 4th February at JFokus.

So it seems like a big release for you – what are some of the key features in Vaadin 7?

We had three different themes in Vaadin 7. We wanted to embrace developers in such ways that we could make it much easier for them to go through the abstraction levels when they have to do that. In Vaadin 6, we've kind of been steering developers towards the server side development model and making some things unnecessarily hard to accomplish. We've tried to kind of take away any kind of barriers that were built into the framework. That's where GWT comes in.

The other one was that we were really happy with the explosion of the add-on system so we want to make it even easier to build new extensions and new components for Vaadin. We added quite a few extensions points in Vaadin, but we also renewed the communication layer that is connecting the client side to the server side, in such a way that it's much easier to write new add-ons now. We also made it much easier to wrap around existing JavaScript components. I would say this third different thing was we did a quite huge spring cleanup in Vaadin 7.

It sounds like it!

One of the biggest examples is the form APIs. Applications are full of forms and editors and in Vaadin 6, we have quite a powerful form concept. The trouble with that is it's not fully customisable and when people are building those forms, they want to customise how they look and how they validate. Then you end wiring quite complicated customisation on top of the default form in Vaadin 6. In Vaadin 7, we've turned that around in such a way that you basically build the form explicitly and then there are helper classes which help bind those forms to the backend data sources. So you can put the customisations directly into your code in the first place and not try to change the defaults after the form has been created.

Thanks Joonas for talking to us!

This interview originally appeared in JAX Magazine: Reality Check. Find more of that issue and others here.


Chris Mayer

What do you think?

JAX Magazine - 2014 - 06 Exclucively for iPad users JAX Magazine on Android


Latest opinions