Interview

Discussing Vaadin 7 with Joonas Lehtinen

Chris Mayer
vaadin-7

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.

Author
Comments
comments powered by Disqus