Why Vaadin - line of argument

While I told in my former post how it came that we left the GWT/ExtGWT couple behind us and finally deciding for Vaadin, I want to elaborate why we think Vaadin is the best option.

First I will explain how Vaadin helps us to solve some of the crucial problems and why it is so effective to build the new AdminCentral with it. Afterward I will response to some valid concerns raised by the Magnolia CMS community.

Benefits

Server side execution
Executing UI events on the server is controversial - more on that later - but it has tremendous benefits.

• Reflection can be used. While GWT code can't use reflection server side code can. This is for instance very helpful when we transform dialog definitions into real dialogs.
• Security respected. At any time we can use ACLs to define what should be possible in the UI.
• Less web services. The UI is build on the server, but rendered on the client. So there is no need to define additional services for receiving dialog and tree descriptors.
  We just have to expose the content related stateless REST services.
• Agility. With GWT it is difficult to support agility as you cannot change the final code without compiling it. With Vaadin we can for instance use our powerful Groovy support.
• Magnolia API. Full Magnolia API can be used and no DTOs are needed.
• Testing. All code can be tested with normal junit test cases. Even the UI code. The server side widget is linked to the client side widget by annotation.

Efficiency
We are a small team and efficiency matters, as time-to-market is crucial.

• Collaboration. The two communities and the backing companies are looking forward to support this collaboration and to help each other to make this successful.
• Documentation. Vaadin's documentation is just great. The Book of Vaadin, which is freely available, makes it easy to get started.
• Compilation. No GWT compilation is needed unless a new client side widget has to be written which should be rarely the case once AdminCentral is rolled out. Composite widgets are not requiring any GWT coding.
• Theming. As many other things theming is a service provided by Vaadin. Once we decided for a design it will be easy to implement a Vaadin version.

Third party and custom modules
It will be much easier to adapt the AdminCentral and plugin module specific UI than if we had chosen for GWT. Firstly one hasn't to perform GWT compilations and secondly reflection/injection will be used to plugin into the AdminCentral.
It is the ultimate goal to make the AdminCentral extendable and usable for more generic content management related use-cases.

Performance Concerns
After the decision was made the community raised concerns about the performance of such a solution. Originally I shared this concerns but want to explain why I think they are not justified or at least don't neutralize the benefits.

Factor in the scenario
We are going to develop the AdminCentral and not the next generation gmail application. The AdminCentral is the backend and is typically used intranets.

Number of Requests
The server side event handling will lead to more requests and will add the network latency to most of the user interactions. This sounds dramatic in the beginning but is it really true? Let's have a closer look.

Scenario A) Ask for data (GWT) = send event (Vaadin)
Most of the user interactions will result in a request to the server. The only difference is the reason for sending it. While GWT will ask for the data to show or send some data, Vaadin will send the event information.
Examples:

• creating a page
• moving a page in the tree
• open dialog
• click save button

Scenario B) One request to rule them all
Note that any client side UI will also request data from the server. So it is actually not unlikely that a client which uses stateless REST services will send more requests to assemble the data its needing.

A typical use-case is opening a dialog for paragraph editing which needs additional information to fill a table or read information from a page we are linking to.

GWT (2 - 3 requests):

1. event -> execute open-dialog action
2. ask the server for the dialog to open and its descriptor (might be cacheable, but not necessary due to some complex rules like paragaph to dialog mappings, ..)
3. populate the dialog -> request to fetch the data details
4. we need some sub-nodes to fill in a table -> request to fetch the data

Vaadin (1 request):

1. event -> immediate request to server
2. event handler builds the dialog (this is fast as no rendering is involved)
3. some data is read. Reading additional information as meta data and sub-nodes are at hand
4. bind the data to the dialog
5. Vaading sends back a JSON representation of the UI changes
6. client side rendering engine applies the changes

Here we actually save requests by Vaadin's roundtrip approach.

Scenario C) Visibility changes - Vaadin says not No to client side events
In other use-cases as clicking on a tab or navigating in menus none of the frameworks sends events to the server. In both cases it is client side code which toggles the visibility.

Conclusion
While we surely expect to have more requests, we don't think that we talk about doubling the numbers of request. In fact I believe that we will not see an increase bigger than about 10-20 %.

Responsiveness of the Demos
Some stated rightly that the ExtGWT examples are snappier. In my opinion this is due to the fact that the examples just don't use server side services to read the data. But is this a realistic scenario? How often will you perform user interactions without having to read or send data?

Example: Sorting in the table
Client side sorting is a nice thing to do, but normally you will request the data on demand (paging). How will you sort the data which you have not received yet?

Optimize where you expect the biggest performance gain
While we can discuss for a very long time about the client performance I think that an end user will judge the overall performance including search, filtering of data, ...

And here we can do much on the server side. I prefer to invest time on that end than to optimize the very last bit and byte sent over the wire.

Content API

• return iterators not collections (same as JCR)
• don't apply the security checks, delegate that to JCR (possible since JCR 2.0) 

JCR / Content Structure

• mixin for metadata instead of using a sub-nodes
• versioning friendly structure: extra node to separate paragraphs and subpages
• use more and proper node types: searching, ..

I am very sure that the resulting responsiveness will benefit much more from this kind of improvements.

Proof of concept
As for now we have decided for Vaadin but still we are just entering a proof of concept phase in which we want to proof that Vaadin is really the better choice. Here are the scenarios we explicitly test.


Page Editing
Here we expect some GWT coding. It is sufficient if the dialogs and toolbox can be Vaadin components.

• show that we can inject behavior into existing HTML: add edit button which opens edit dialog
• mouse over: show paragraph information on mouse over
• inline editing: proof that inline editing will work

Tree Grid
Vaadin is working on the tree grid. If we find some shortcomings they will most likely help to improve it.

• move: drag and drop
• context menu: per node type
• editable row

Paragraph
If we use a technology to build the new AdminCentral we want to ensure that it can be used to write more complex paragraphs as well. As an example I take the page commenting. Each page has a commenting paragraph. The scenario is different as it must work for high traffic websites too.

• initial form should not create a session (the page should be served by the cache)
• coexistence: two independent Vaadin paragraphs
  

Conclusion
We really think Vaadin has great potential and deserves its chance. Still we are new to that technology and will have to verify that our assumptions are right.

We won't rush into anything