Episode 24
While being in the topic of web framework research: another one I’m considering to use is Vaadin. It has been around for quite some time, over 10 years now, so we can say that it’s mature (or “old”, if you like). Anyway it has large and active community, and is quite popular which is always helpful.
Vaadin is a server side centric framework, meaning that all content is rendered to html and passed to browser on each request. It’s a bit old school approach. Nowadays it’s more popular to keep as much as possible on the client side, mostly as Java Script and communicate with server only when needed. Vaadin guys argue that server side approach is safer, because it’s impossible to temper with the executable code.
There are other pros and cons, but what is important to me, that current version of Vaadin uses GWT as rendering engine. As you may recall from previous article I’m a big fan of GWT, since I believe that having all code in statically typed language under decent IDE control is a must for any non trivial web project (I’m yet to meet a happy Java Script programmer after successful and pleasant refactoring). But enough introduction, let’s get down to business.
To start easily with Vaadin I recommend The Vaadin Book. You can get it for free from Vaadin website (after registration, but still nice move). In short: get the Ivy and Vaadin plugins for Eclipse, then create new Vaadin project. To make things simple, you can ask the plugin to create project stub. We will rewrite it just a bit then to get something similar to what we had in articles about GWT and Spring.
In order to get things going we actually need only two classes. First doesn’t even have any code, just two annotations and a parent. It’s a Servlet class with a standard url mapping (this time as an annotation) and some Vaadin specific configuration to associate with GUI content class. Also, it extends VaadinServlet.
The content class needs to extend UI and implement init method where the page is created and hooked much like in GWT entry point. The @Theme annotation is optional, it provides us a default css and makes our button look nice. I’ve also added a Service class as our “backend”. Since everything is on server side, you don’t need synchronous and asynchronous interfaces, rpc mappings, callback and all that stuff. Just create class and call method (it’s an example, in real life you would want to have some dependency injection here). That’s all, deploy on server, run and enjoy your Hello World.
Comparing to pure GWT, Vaadin is much simpler to start. You don’t need any html to hook your Java code. You don’t need server communication handling. You don’t need module definitions in xml. You don’t need dev mode and all the acrobatics to debug client side code. The price is however page responsiveness. I’m not sure if it’s a high price though, keeping in mind an average modern bandwidth and latency. And you still keep all the luxury of not worrying if your method gets three Cats instead of two Dog it expects.
There is also a possibility to write client side code in pure GWT and integrating it with Vaadin but it pretty much brings all the GWT complications back.
Still better than JavaScript :)