Discussing Vaadin 7 with Joonas Lehtinen

Chris Mayer

Originally in March’s JAX Magazine, we chatted to the creator and CEO of Vaadin about the team’s release that had been 18 months in the making, as well as their commitment to Google Web Toolkit

Originally in March’s JAX Magazine, we chatted to the creator and CEO of Vaadin about the team’s release that had been 18 months in the making, as well as their commitment to Google Web Toolkit

JAX Magazine: For those who are unaware, just what exactly is Vaadin?

Joonas Lehtinen: As a starting point, Vaadin is a framework for building rich Web applications. The basic idea is that you can write fully modern rich Web applications just by writing Java on the server side. So when you’re running Java on the server side, it basically means you have all the tooling, all the libraries, all the frameworks – everything you already have been using and you know already. All of that is available for you. Vaadin then creates the UIs automatically on the browser side. 

So it’s trying to find a middle-ground between the two?

If you think about the original way of building rich web applications, you have been building the basic user interface in HTML and JavaScript on the client-side, then you have decided some kind of web APIs that you are publishing, the REST APIs. Then next you are building a server side service layer where you are doing all the backend producing for the user interface. In most cases, you have a real backend layer that does additional operations. In Vaadin, you build the server side layer and that’s it. The rest comes automatically. 

So how many people use Vaadin at the moment?

Statistically, we are looking most carefully at how many unique visitors we are seeing on the community side, at the moment 105,000 on a monthly basis.

What reasons did you have originally for creating Vaadin, and do those core values still apply today or has the role changed over the years?

The original reason was that I was leading a team in 1997 that were building a hospital system. That was quite a complex web application that we built in Perl and the tools of the day. It became kind of huge pile of spaghetti in the end, because we didn’t have any proper tools or libraries for it, so we actually started of thinking of Vaadin already in 2000.

First, we wanted to build a tool for ourselves then we kind of fell in love with the tool and decided to open source it and release that to the public in a distribution in 2002. I guess the reasons for building Vaadin are still there and the values that we were sitting in 2000 are still there. We still try to reduce complexity. We still try to make building nice looking UIs for web as simply as possible. This is in the business context, not a tool for writing a website. It’s a tool for writing business applications. But as you can hear the history is quite long – it’s already a 12 year-old framework and that’s part of the reason we wanted to build Vaadin 7. 

Can you explain someone of the core concepts behind Vaadin?

It’s a UI library, so everything you see is concentrated on UI Components. The basic idea is that you build the whole UI just by composing it from ready-made components. There are few UI frameworks around like Swing, that just put components within other components then wire them up and they start behaving as a user interface. We have been really focused keeping our thinking on the UI layer and for the Web. Extending from there, we have data bindings from the UI layer to various kinds of data sources. We have different tools for customising the user experience – how it looks, how it behaves and so on, but still the core is the UI components.

I would say that makes Vaadin quite different from most of the competition where most of the UI components actually live on the server side memory. You can just compose in pure Java or in fact in any JVM language on the server side and expect all of the user interactions to be handled over for you in the server side. You don’t have to think about how these user interactions actually are sent over the wire to the web browser, how they are rendered and how browsers behave differently. Most of the time, you can think at quite a bit higher level, in trees and tables and tabsheets. Not like HTML Elements and CSS styles.

I think you touched upon on it there – what separates you from other JVM frameworks?

It’s mostly used by quite large projects. We try to find a nice balance between developer abstracts and how much you help control the presentation, but still keeping the building of the UI and maintaining of the UI relatively easy and compact.

There also seems to be an ability to mix and match too – it seems quite customisable. Is that a goal you had in mind also?

Definitely. One of the most powerful concepts we introduced a couple of years ago was a component directory. So now we have a directory where the community can send their own components so that people can reuse them. The nice thing is that we really nailed the packaging of the components, the distribution of them and how you start to use them. The community has now submitted 300 components in there, such as adding a Maven definition into your pom file or download the component and Vaadin takes over and integrates the component automatically into your application.


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.

Inline Feedbacks
View all comments