When I started to work with Vaadin, I quickly realized that this is not the framework I want to be an expert in. It was used in different projects across the teams and now the tendency is common – to get rid of it. Here are some thoughts on that matter – with lesson learned.
When you could use Vaadin
- You are a Java purist and do not want to get dirty coding the front-end
- You have no front-end developers in your team
- You have to provide the client with rich UI fast
- The UI will not change too often
However, if you are already there, you meet common problems very quickly.
Missing coding guidelines
You have to be careful writing applications based on Vaadin. You can end up with spaghetti code. Vaadin misses coding guidelines in contrast to GWT, which it is paradoxically based on.
- Consider using correct design patterns like MVP for instance
- Avoid writing business logic witihin the Views
- Be aware of the OpenSessionInViewFilter anti-pattern
- Develop a coherent exception handling and error messages for the user
Painful customization
Generated html and css is far from that you would like to see. It is incredible hard to customize your front-end. Finding the equivalent of html or css features on Java classes isn’t always so obvious.
In spite of a rich interface, you often find yourself missing something special you need. Implementation of custom features takes time and energy.
Bumpy learning curve
Vaadin component architecture is dominated by multi-level inheritance. You got lot of components and available plugins. The whole solution is built upon GWT under the hood. It is barely possible to get to know the whole call stack. Need to up stumbling terribly to know what and in what order to call to get your job done.
The image below illustrates the controversial architecture. I counted a few hundred of methods accessible in one component – ComboBox – inheriting from four other classes.
Thinking about U and I
The quite catchy slogan of Vaadin – Thinking about U and I – does not reflect reality. Vaadin UI is very coarse and uncomfortable both in development and user experience. The Vaadin slogan much more refers to authors and to fact that they’re thinking about themselves only (?).
Why write HTML in Java ?
That’s the first question I asked myself starting to work with Vaadin, and I suppose it’s important to ask that yourself each time you are about to choose that framework.
I can image only two scenarios mentioned before: – you are a java purist and do not want to get dirty coding the front part; – and you haven’t got front-end developers in your team.
Some also say they do not have to think about compatibility between browsers. Let me think… well… wait until all your widgets will compile… 🙂