Video: Joonas Lehtinen speaks about Vaadin and HTML5

At JavaOne, TheServerSide got a chance to talk with Vaadin CEO Joonas Lehtinen. Oracle had just unveiled their HTML5 strategy, known as Project Avatar, and we wanted to hear about what Vaadin was already doing with regards to Java development, the latest HTML standards, and even rendering to iPhone and tablet-type devices.

Joonas: We have already moved rich web development to the ServerSide. So, with Vaadin, everything is done on the serverside using Java or any other JVM language suchs as Scala or Groovy. So, you can build HTML5 applications today with Vaadin, on the serverside, and you can deploy them to devices like the iPhone, iPad or traditional desktop browsers.

TheServerSide: You mention Scala as a viable development language for Vaadin. Are you seeing Scala adoption growing?

Joonas: It's growing really, really fast. For me, I think it is the most natural language that people are moving to from Java.

TheServerSide: What is the key competitive advantage Vaadin provides over competing technologies in this space?

Joonas: We are bringing everything to the serverside. We are basically removing two layers of complexity. You don't have to worry about communication. You don't have to worry about the  rendering on the client side. So, you are basically saving yourself half of the code lines on the UI layer with Vaadin.

TheServerSide: Have you been to JavaOne before?

Joonas: We have been here four years in a row.

TheServerSide: How does JavaOne 2011 compare to JavaOne 2010?

Joonas: This is definitely better. Much, much more lively.

TheServerSide: And how can people find out more about Vaadin?

Joonas: Got to Vaadin.com. It's a free framework. You can use it for anything you want. And there is a great book about Vaadin at vadin.com/book

  Video: Joonas Lehtinen speaks about Vaadin and HTML5

TheServerSide: You mention Scala as a viable development language for Scala.

lame

You mention Scala as a viable development language for Scala

And by the same account, Java is a viable development language for Java ;)

Seriously, the all-Java approach taken by Vaadin is interesting. I do notice some confusion about Vaadin though, as it's often called a sibling of GWT. The irony is though that GWT is completely a client-side thing, while Vaadin is exactly the opposte; completely server-side. It's just that Vaadin uses GWT's widgets. (correct me if I'm wrong).

In that sense, Vaadin seems closer to JSF and Wicket. Both are completely server-side in their core architecture. Wicket also more or less claims to be about pure Java, but in reality Wicket components need to be matched to their associated placeholders in the html template.

JSF normally doesn't claim to be about pure Java at all, but instead by default emphasis templates with (bi-directional) data bindings to backing beans. However, it has always been possible to build a JSF UI with pure Java because of the complete decoupling of the way a UI is composed and the rest of JSF. JSF has the explicit notion of a View Description Language (VDL), and these are pluggable. It's just that apparently nobody ever demonstrated how to do this.

Recently, at approximately the same time, two projects have surfaced that do demonstrate this, JavaVDL and JavaJSF. See http://jdevelopment.nl/single-class-pure-java-jsf-application and http://java.net/projects/jsf-extensions/sources/svn/show/trunk/code/run-time/javajsf 

I haven't found an article about JavaJSF yet, but the following file in the project shows what it looks like: http://java.net/projects/jsf-extensions/sources/svn/content/trunk/code/run-time/javajsf/examples/sandbox/hellojavajsf/src/main/java/javajsf/demo/ui/MainUI.java

I read on Twitter that JavaJSF is inspired by Vaadin, so it will be interesting to see how they match up.

Vaadin actually uses only one widget directly from GWT. Instead of that, it uses the brilliant java-to-javascript compiler from GWT as well as some of the client-side API:s to gve a solid base to build and extend Vaadin "widgetset" (client-side rendering engine).

While as Vaadin is a server-side framework and heavily promotes server-side programming, it allows development on three layers of abstraction: 1) server-side java, 2) client-side java compiled with GWT and 3) client-side javascript. This model allows one to get everything browser has to offer, but keep the most o the UI code on the server-side. 

At the moment JavaJSF is probably not meant to "match up" with Vaadin. It is a prototype, while as Vaadin has over 10 years of development behind it. That said - it is interesting to see that one could use JSF in somewhat Vaadin like manner. Maybe Ed Burns could say more about this topic...

Vaadin actually uses only one widget directly from GWT. Instead of that, it uses the brilliant java-to-javascript compiler from GWT as well as some of the client-side API:s to gve a solid base to build and extend Vaadin "widgetset" (client-side rendering engine).

I see. So with respect to using the client-side API of GWT, it's a little like the RichFaces and PrimeFaces component libaries for JSF usage of JQuery, isn't it?

Didn't know Vaadin used only 1 explicit widget from GWT though.

While as Vaadin is a server-side framework and heavily promotes server-side programming, it allows development on three layers of abstraction: 1) server-side java, 2) client-side java compiled with GWT and 3) client-side javascript. This model allows one to get everything browser has to offer, but keep the most o the UI code on the server-side.

Hmmm, so the difference with GWT is that GWT emphasis level 2) and allows level 3), while the difference with JSF is that JSF emphasis level 1) and also allows level 3) as well.

JSF does starts to support level 2) a little bit via the so-called 'behavior' support, that e.g. automatically generates client-side validation code based on server-side Bean Validation constraints, or transparently turns server-side controls into AJAX enabled ones. The support for this "level 2" in JSF is not up to the level that GWT and Vaadin supports, as it's more a declarative thing while GWT supports universal Java code, but there's thus some development in that area.

Ed Burns recently wrote about some of this here: http://weblogs.java.net/blog/edburns/archive/2011/09/26/position-paper-html5-jsf-22

At the moment JavaJSF is probably not meant to "match up" with Vaadin. It is a prototype, while as Vaadin has over 10 years of development behind it. That said - it is interesting to see that one could use JSF in somewhat Vaadin like manner. Maybe Ed Burns could say more about this topic...

I agree with that yes. On the one hand JSF has always allowed the Vaadin like manner (JSF 1.0 supported this), but it always has been only used as an internal API for VDL authors (e.g. Facelets used this API to do what it does), and at most to allow 'normal' developers to insert some components programmatically in an otherwise declaratively created view. Vaadin has focussed for 10 years on directly offering this API to the actual page creator.

It would be interesting to see what Ed Burns' official stance is here. Do JavaJSF (and JavaVDL) remain prototypes, will they migrate to mature projects, or will this way maybe be officially incorporated in the core spec one day?

I see. So with respect to using the client-side API of GWT, it's a little like the RichFaces and PrimeFaces component libaries for JSF usage of JQuery, isn't it?

Somewhat. The important difference is that GWT is not "an add-on" to Vaadin. It is the default mode of operation built in the core. All of client-side side is done on top of GWT. It is a perfect fit because both client- and server-side are built in Java.