My first encounter with Vaadin was during the “Orignal1 project”. At the time we were looking for a user interface framework that was suitable for an externally available administration interface that was expected to
- support few but demanding users that should get a rich user experience;
- have a very streamlined, repetitive look and feel – no surprises when moving between views;
- not be layout driven (no pixel perfect visuals);
- become rather data centric and will require a lot of desktop-style interaction for data maintenance;
- become subject to a lot of extensions over time.
Nobody in the team knew about Vaadin at that time (as far as I can remember – although the larger part of the team was located in Helsinki!). There was a lot of experience with design-driven mass-user Web sites on the team, also some for snappy, highly interactive rich client sites. Plain HTML or Sencha-style rich clients were quickly dismissed though for the problem of balancing productivity, extensibility, and user experience in the niche we were moving into.
When Vaadin was brought up, it only took a few samples to be convinced – despite its name that doesn’t sound too impressive for anybody not from Finland.
The downside of Vaadin is that one frequently has the feeling that the APIs could be somehow more elegant. On the plus side, considering our constraints, you get:
- It’s all Java code. No other markup required (except for theming of course)
- As its all Java, you can build composite controls, your own utility controls, anything unless when you want different HTML (in which case you need to compile GWT widgets).
- As it is all Java, you can put your composite controls and utilities in re-use modules – including their resources (e.g. images).
- As it is all Java, you can refactor directly from your IDE
- Productivity is only limited by the quality of your application structure and re-use assets (and your dev environment of course)
- It comes with a rich control set and there is an impressive add-on community
So, currently at least, if somebody asks for a toolkit to build intranet and “complex+few users+very much under maintenance” user interface, Vaadin is a safe choice.
I promised a sample. It’s here:
Sample-vaadin-spring-hibernate
It is very much like the other samples in our Wiki. And as before we use Spring to inject dependencies into the UI layer whereever needed. Which is kind of the point here. Vaadin was used just as a drop-in replacement for other UI implementations and it simply fit in – without any bending and plumbing.
z the world 