Home > Point2 - Technical > First Look at Vaadin

First Look at Vaadin

November 22, 2009

I’ve had the chance over a recent weekend to have a first crack at a web framework called Vaadin.

I was originally browsing for news about the latest release of Google’s GWT framework when I stumbled on a reference to Vaadin, and decided to go take a look. What I found intrigued me, and I decided to take it for a test drive, as I was down sick for a couple of days with a laptop nearby…. My back became annoyed with me, but it was worth it, I think.

First Look
First off, the practicalities: Vaadin is open source, and with a reasonable license, the Apache License. The essential bits of Vaadin are contained in a single JAR, and it’s both Ant and Maven friendly right out of the box.

The next thing that struck me about Vaadin was the documentation. The first unusual thing about it’s documentation was the fact of it’s existence, as open source projects are downright notorious for poor documentation. Vaadin is a pleasant exception, with tons of examples, a well-organized API doc, in the usual JavaDoc format, and even the “Book of Vaadin”, an entire PDF book (also available in hardcopy) that takes you through Vaadin in enough detail to be immediately productive.

Given that surprisingly pleasant start, I dug deeper, creating a little app of my own.

Just the Java, Ma’am
The main thing that kept me interested in Vaadin once I started digging further was that it’s pure Java. Many frameworks talk about writing your UI work in Java, such as Wicket, but there’s still a corresponding template and some wiring that happens to put the code and the template together. Not so with Vaadin.

When they say “just Java”, they mean it – your entire UI layer is coded in Java, plain and simple. No templates, no tag libraries, no Javascript, no ‘nuthin. It’s reminiscent of the Echo framework, except in Vaadin’s case the Javascript library that your code automatically produces is Google’s GWT, instead of Echo’s own Core.JS library.

Unlike GWT, though, the Vaadin approach doesn’t bind you to any specific source code though, it’s just a binary jar you put on your classpath.

The only thing in my sample app, other than 2 Java files, was a web.xml and a css stylesheet, both of which were only a few lines long. And this was no “Hello, World”, either, but a rich AJAX webapp with a tree menu, fancy non-modal “fading” notifications, images, complex layouts, and a form with build-in validation. And it took maybe 4 hours of total work to produce – and that was from a standing start, as I’d never heard of Vaadin before last Thursday. Not bad, not bad at all.

I found I was able to get a very capable little webapp up and running with no need to invent my own components, even though I had trees and sliders and menus and other assorted goodies on the page. It worked in every browser I was able to try it in, which is certainly not the case for my own hand-rolled JavaScript most of the time 🙂

I haven’t yet tried creating my own custom components, but it certainly looks straightforward enough.

I did try linking to external resources, and included non-Vaadin pages in my app, with no difficulties, so it appears that Vaadin plays well with others, and can be introduced into an existing project that uses, for instance, a whack of JSP’s that one might want to obsolete.

Webapps
I think Vaadin warrants more exploration, and I intend to put it further through its paces in the next few weeks. It appears extremely well-suited to web applications, as opposed to websites with a tiny bit of dynamic stuff in them.

It offers an interesting alternative to some of the patterns I’ve seen for advanced dynamic webapp development so far.

One approach I’ve seen a lot is to divide the duties of creating an app into the “back end” services and the “UI”. Generally the UI is written in either JavaScript, or uses Flex or some other semi-proprietary approach. The “back end” stuff is frequently written to expose it’s services as REST, then the two are bolted together. The pain point here happens when the two meet, as it’s common and easy to have minor (or major!) misunderstandings between the two teams. This usually results in a lot of to-and-fro to work out the differences before the app comes all the way to life.

The other approach, more common on smaller or resource-strapped teams, is to have the same group responsible for both UI and back-end services. This reduces the thrash in the joints a bit, but doesn’t eliminate it, because the two technologies on the two sides of the app aren’t the same. You can’t test JavaScript the same way you write Java, for instance, and they’re two different languages – one of which (Java) has far better tooling support than the other. IDE support, for instance, is superb for Java, and spotty at best for JavaScript.

With Vaadin, both of these approaches become unnecessary, as its the same technology all the way through (at least, what you write is – technically it’s still using JavaScript, but because that’s generated, I don’t count it).

You get to use all of the tools you know and love for the back-end services to write the code for the UI, which you can then unit and functional test to your heart’s content.

The temptation to mix concerns between UI code and back-end service code must still be resisted, of course, but at least that code isn’t buried somewhere in the middle of a JSP page, ready to leap out and bite you later.

Because you’re using dynamic layouts, the app always fits properly on the screen without any extra work, addressing a pet peeve of mine, the “skinny” webapp, restraining itself to the least common denominator of screen size, thus rendering impotent my nice wide monitors.

Scala
Just because Vaadin is a Java library doesn’t restrict you to using Java to drive it, however. I made another little webapp where the whole UI was defined in Scala, calling the Vaadin APIs, and it worked like a charm. In some ways, Scala is an even better fit for Vaadin than straight Java, I suspect. I haven’t tried any other JVM compatible language, but I see no reason they wouldn’t work equally well.

Deployment and Development Cycle
As I was building the app with Maven, I added a couple of lines to my POM and was able to say “mvn jetty:run” to get my Vaadin app up and running on my local box in a few seconds. My development cycle was only a few seconds between compile and interactive tests, as I was experimenting with the trial-and-error method.

TDD would be not only possible, but easy in this situation.

I successfully deployed my little Vaadin app to ServiceMix, my OSGi container of choice, without a hitch.

Performance appeared excellent overall, although I haven’t formally tested it with a load-testing tool (yet).

Summary
So far, I’m impressed with Vaadin. I’m more impressed with any web framework I’ve worked with in a number of years, in fact. I’m sure there are some warts in there somewhere, but for the benefits it brings to the table, I suspect they’re easily worth it. I think the advantages to teams that already speak fluent Java is hard to overstate, and the productivity to produce good-looking and functioning webapps is quite remarkable.

Over the next few weeks I’ll push it a bit harder with a complex example application, and see how it stacks up against other web app technologies I’ve worked with in a more realistic scenario.

By: Mike Nash

Advertisements
  1. Jack
    December 31, 2009 at 9:51 PM

    Hi Mike,

    Good write up! I’m also interested in using Vaadin with Scala but I have a concern if it’s easy to do a tradition web page type of application with Vaadin. There’s some discussions in this page on Vaadin forum:

    http://vaadin.com/forum/-/message_boards/message/41332

    It sounds like you have to do something special to achieve that. You mentioned that you tried linking to external resources, and including non-Vaadin pages in you app. I would if you could describe what exactly you tried – my (limited) understanding is that if it’s a Vaadin app, everything will happen in Vaadin and you will have to build all UI in Vaadin. I’d imagine that you can bind a particular URL to a Vaadin app and do things differently with the other URLs but I suppose the UI will look inconsistent. So I’m curious about what you tried.

    Thanks.

  2. David
    January 8, 2010 at 5:23 PM

    It’s been a little over a month since you first posted this.

    How goes your more in depth look? Our main concern is scalability of users with everything in the server. But as a Java programmer, it does look intriguing to me as well.

    Our team made the choice to try GWT for its Java-centric model, but we quickly found it was lacking many widgets to easily build typical business apps with paging lists of tables and such that often are read-only, but just as often have standard CRUD needs. And then all of the DTOs that needed to be created to move to/from client/server was rather painful.

    Coming from a JSP/servlet environment, having everything on the server doesn’t seem bad at all to me, so long as performance and scalability are not sacrificed.

  3. joseph
    March 4, 2010 at 1:44 AM

    agreed with jack and i will add:
    vaadin environment is nice but the documentation and support is not that powerful towards some stuff and as an example for that is trying to create an application with your design and customize it to be workable in vaadin . i didnot find enough help or support even in the forums.
    to my understanding every article on the web related to vaadin is just for publicity and advertising every body trying to say about his experiments with vaadin but not giving a full example – it is something annoying to be frank and want to have a live example about that try google “vaadin form example” – all the results you want will guide you to 25% about vaadin book which is full by a lot of literature that i dont need it as a programmer . 50% developers tickets and the rest is crab.

  4. David
    March 5, 2010 at 11:18 AM

    Not sure “joseph” actually agreed with “Jack” or not, but I found the Vaadin documentation to be more complete than most libraries, and the examples more complete as well. We reviewed pure GWT, SmartGWT and ExtGWT and found their examples less compelling once you tried to build true client-server apps moving data from the server to the client and processing add/change/delete operations on that data.

    If you love the java servlet environment and are building an ajax “single page” application (you can have all the views you want, but it’s not designed for a webpage-per-view model), you should love Vaadin. If you prefer to do javascript+HTML, or create traditional multi-page web sites, probably not.

    As for “all Java” that’s true as long you also understand HTML/DOM/CSS since you will need to understand it to control the browser look, though that’s rather to be expected if you’re building a web front end.

    Sure, there always could be more sophistication in the examples, and more are coming all the time. There’s a rather large incubator and contrib library that shows many usage patterns and some frameworks and many widgets, and they are packaging this nicer in a Directory application they are building now — though I don’t know if they have any plans to make the Directory code itself open source or not.

    Our own app on Vaadin is open source (open.esignforms.com) albeit at a very early stage as we just concluded to use Vaadin ourselves, so you can certainly read that code, but most apps built with Vaadin are proprietary, so you’re outta luck reviewing that code. But you can’t criticize the open source framework because others who use it keep their IP and hard-work to themselves — well, you can if you prefer GPL to Apache 2.0 licensing.

    And another thing is to be considerate and helpful — abuse in some of the other forums was disappointing, and I’ve not seen that in Vaadin’s forums yet. If you ask questions on the forums and say “the rest is crab” and “vaadin book which is full by a lot of literature that i dont need it as a programmer” and “documentation and support is not that powerful towards some stuff” you may not get good answers because it’s grumpy and unclear and imprecise — nobody is going to develop “your design” for you — that’s your job. The book is pretty good for getting started, coupled with the tutorial, but yes, I wish it had more easy to get examples too since it would make my life easier, but learning takes time and effort just like you can’t be a great Java programmer by looking at Sun’s website and then grumble Java sucks because you’ll need to learn and write code yourself. I mean, you can’t really expect you’ll just be able to build a sophisticated new application without learning the platform — it can’t be done in GWT, ExtGWT, SmartGWT, JSP/servlet, ASP.NET, PHP, any framework you name or anything else either. Anything worth being developed may be hard to do as the easy stuff is already done.

  5. joseph
    March 8, 2010 at 7:01 AM

    David i think you got offended , perhaps you misunderstood me ,i would like to inform you that i dont have any intention to offend anybody, iam just telling my opinion very clearly and in a polite way also , mean while i think you have prove my point of view by attacking me that i need somebody develop “my design” , no sir.
    iam an 18 years java programmer and iam using open source technology for a very long time , i do appreciate people who are doing open source to make other people happy.
    building a forum to support and to gain experience from other users is really very helpful but in your forum i just can find (“i build an application with vaadin , yeppyyyyyyy – i love vaadin”)no description , i have even found some users send question and still without reply till now so admit that you are not ready yet to publish and announce that you have something that i can depend on . other point to still prove my point of view you didn’t come by any examples that can help developers build there application using your vaadin.
    “grumby , unclear , imprecise , abuse” are really not the right words to reply for criticism that is extreme paranoia.
    however i dont think you have a negative energy , please take critic on a positive way.

  6. David
    March 8, 2010 at 11:15 AM

    I take no offense, Joseph. While a new user of Vaadin, I’m not a Vaadin developer so it’s certainly not personal. I just think your criticism would be more valuable if it were more precise is all. Unpaid support via the forums has worked well for many of my questions, but sure, they’re not all answered or are answered slowly. That’s true in many forums; I get far fewer answers from the CKEditor forum, but still like that editor as well.

    As for “full example,” did you do the 5 minute tutorial? Then the 1 hour tutorial? http://vaadin.com/tutorial

    As for the book, I’m not sure why you found it useless and is just “literature,” since it has sections on getting started (with more detailed setup using Eclipse than most), architecture, webapps, UI components, layout, themes, binding components to data, custom components, advanced webapp topics, and info on UIDL which is their RPC mechanism if you’re building widgets. I found it helpful after I did the tutorials and had some understanding of building a working app that included simple navigation, a searchable table component that linked to an ACID form. Before, it seemed too detailed to me.

    Personally, I would like to see more details on using Property/Item/Container, and I wish the javadocs explained more what some of the Object parameters really are (or what they can be). Another example, in TwinColSelect, it turned out I need to get/set java.util.Set for the beans and not HashSet (though of course my bean could use HashSet internally).

    Is Vaadin perfect? No, of course not. It’s been around, but it’s also somewhat new and growing with a new directory to organize the incubator and contrib code. I have found most answers to be helpful rather than critical. Sometimes I do have to figure it out myself (hey, that’s my job), but since I can run the debugger into all the code, it’s a lot less trouble than non-Java, non-GWT-JS debugging, and can figure out what those pesky Object params really are.

    No problems, Joseph. Use Vaadin or not. I have no vested interest. But I know if you state a single problem clearly, there’s more chance you’ll get a response, and then if you need more reliable support, perhaps you need to purchase some of the Vaadin support/services — and then report back on your experience since I’d be interested to know about its quality…they did seem expensive to me at 2700 EUR for just 3 months (which comes out to nearly US $14,700/year) for the lowest end “developer” support.

  7. March 8, 2010 at 5:02 PM

    Hi All:

    I’ve been meaning to post a detailed followup to this article, but we’ve been too busy for a bit to allow much blogging time.

    We are now using a Vaadin app in a couple of “real-life” projects, and it’s working out very well for us.

    We can easily intermix Vaadin and a JSP-based older app, static pages, as required.

    We too are concerned about the scalability issue, but it turns out that our test show it scaling at least as well, perhaps better, than many of the alternatives. (Again, details later…).

    Mike

  8. Yuri
    January 25, 2011 at 2:25 PM

    Hi everyone,

    We have started using Vaadin in different projects about 3 months ago.
    I agree with the someone saying “Vaadin is not perfect”, but have to add that it is really really something you will never want to leave once you’ve tried.
    We are developing business applications with lots of forms, tables, etc. and Vaadin is really great that.
    Also it runs perfectly in portals like Websphere Portal Server or Liferay.

    What else do you need?

    Just try it!!!

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: