Vaadin is pleasantly productive

I think Vaadin 6 is the first truly productive web UI framework I've worked with. Productive for me, anyway; experiences will vary depending on the task at hand and the developer.

I strongly recommend Vaadin 6 for anyone doing web applications - highly stateful tools where user counts are relatively low and UI complexity is relatively high.

The only real caveats I have to that recommendation are that:

• JPAContainer is very inefficient - largely due to an API design problem in Vaadin's Container API that makes it very hard to use the entity manager efficiently. Alas, this design flaw hasn't been remedied for Vaadin 7, so it's sometimes best to avoid JPAContainer and drive a Vaadin table from the outside instead.
• JPAContainer doesn't play well with Hibernate and lazily loaded entities. A workaround is provided, but it's clearly more used with EclipseLink. This won't be a problem if you drive your tables with your own data model code.
• Vaadin's stateful design means that each client costs you a non-trivial amount of memory on the server. If you want to serve large numbers of users who're doing simpler things you might want to consider a stateless JAX-RS API driven by client-side JavaScript and a lightweight templating engine, or look into one of the stateless server-side frameworks.

Vaadin 6 feels a little bit old at times, and you can certainly see its Java 1.4 history in more frequent use of casts rather than generics. It also requires an extension to integrate it with CDI - even then, only with pseudo-scopes.

Vaadin isn't beautiful, but damn, it works. Works well, and reliably. It's been at least two weeks since I found a bug in the tools I've been using, and that has never happened to me since I started using the Java EE stack!

Despite its flaws, JPAContainer is also impressively powerful. I really hope an enhanced Container API can be introduced to Vaadin 7 so it can reach its potential as a truly awesome RAD tool.

Be careful if using Vaadin with Maven

As I'm getting more and more sick of bugs in JSF2 and RichFaces 4 and making painfully little headway, I thought I'd give Vaadin a go with a side project I'm fiddling with.

First impression, three hours in: The Vaadin developers don't use or get Maven, and while there's official Vaadin support for Maven their support is only superficial. The Vaadin Eclipse plugin only kind-of works with m2eclipse, scattering generated files throughout the src/ tree, putting library jars in src/main/webapp/WEB-INF/lib, adding jars directly to the Eclipse build path for the project, etc. It's not really a good maven citizen and needs plenty of encouragement to do the right thing, though it does seem to work once you've undone all the damage it does when enabled on a Maven project.

To clean up, you seem to need to:

• Enable the Vaadin facet in your project properties Project Facets section. Do not click on "Further configuration available..." or, if you do click it, make sure to uncheck "Create project template..." if you already have the vaadin servlet in your web.xml.

• 
  Check web.xml to make sure the Vaadin facet hasn't added a second copy of the vaadin servlet when it was enabled.


• Remove src/main/webapp/WEB-INF/lib and instead add a dependency on com.vaadin:vaadin:6.7.1


• Also add a dependency on com.google.gwt:gwt-user:2.3.0 because the vaadin artifact pom doesn't declare the dependency


• In your project properties, under java build path, remove the VAADIN_ entries from the Libraries tab. Otherwise you'll have those on the build path as well as the Maven-provided dependencies, which could get mismatched-versions-tastic in a hurry.


• Add src/main/webapp/VAADIN to your .gitignore; it contains generated code that's being dumped there not in target/.

In my first three hours with Vaadin, I reported seven bugs, though only three are more than cosmetic/trivial and are reproducible. Not a reassuring start, but I'm going to give it a chance because they're all related to Maven integration in the Eclipse plugin and to slightly dodgy artifact packaging. They might make a great tool and just not get Maven.