Why Vaadin - proof of concept

Now, three weeks after deciding for Vaadin, we have finished the very first prototype.

To complete the current sprint we have released the result as the first milestone. We created a short video to demonstrate the current status so you don’t need to install it yourself. Please be aware that we have not focused on things like user experience design and theming. We just wanted to implement a mini AdminCentral and prove that Vaadin works for us.


Video: by Federico Grilli

Note: if you use the current milestone release you will have to point your browser to /AdminCentral/ as otherwise the old AdminCentral will be served. We will switch that as soon the new UI is functional enough.

Our experience
We had a quick start and were able to implement things like the tree view, accordion menu and dialogs very quickly. So Vaadin definitely fits our team and will fit other Java oriented teams well.

Extensibility
It is the ultimate goal to make the new AdminCentral extensible so that everybody can contribute rich modules and paragraphs to the system easily. As expected the server side characteristic of Vaadin helped a lot and allowed us the improve the wiring of the components:

• Provider interfaces for the various elements (dialog field, accordion menu actions, ..)
• No dependency on the Content API
• DSL/Builder APIs can be build easily (not yet done)
• All is instantiated/configured by Content2Bean

History support
We still need to improve things but the accordion menu already supports history, and if you switch the tree views (website -> config -> website) you will see that the state of the former selection is kept. We also want the complete status (selected page) to be “bookmarkable”.

Page editing
It was the goal to prove that we can embed a Vaadin application into an existing web page and that we can inject Vaadin components like the edit bars or dialogs. This worked, and since the client side coding is done in GWT, we did not need to leave the Java world. As always, once you leave the well-treaded path you have to overcome obstacles but we learned a lot, found traction and finally succeeded.

Now that the basics are done, we will have to optimize the initial loading time. The produced script is definitely not small (170k) and has to be cached. Setting the correct response headers will do its job. We also plan to add the edit bars already in the GWT entry point and only bind them later to the server side components. It might be that we even move bigger parts of the code to the client side, but since this is GWT backed code, it is not different from what we had to do in the "Plain GWT" approach.

Next steps
Many things were done and decided quickly so we need to finalize and clean up in the next sprint (the last before the conference). Therefore, we will improve the naming and streamline the architecture a bit.

Now that we can build the dialogs by code we want to show that it is feasible to write a nice dialog editor. How fancy is that!

Looking forward to discuss/argue at our conference ;-)

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

Why Vaadin - the Odyssey

Before I write why we have chosen Vaadin I have to wrap up how it came that we queried our first choice: GWT/ExtGWT.
After the first two Magnolia 5.0 sprints we realized that we have to reconsider our initial decision. We still liked the GWT approach but also faced some challenges which justified such a step.

• All in one compilation. To optimize the resulting JavaScript code GWT removes unused methods and shortens the names. While this produces minimal and fast code, the outcome is unpredictable and prevents method calls from one module to the another unless they were compiled in the same step. In Magnolia CMS you will install additional modules or update them at run time. This requires a recompilation of the whole AdminCentral unless other tricks are applied.
  We planned to re-compile on demand but this conflicts with the exhausting compilation time. Delivering non-optimized JavaScript was also considered. And finally we opted to expose some methods by using gwt-exporter but this would reduce the interoperability of modules.
• Compilation time. The GWT compilation time increases with the number of inherited modules (ExtGWT is quite heavy) and the produced permutations (browser, languages). If we want to support 5 browsers and 10 languages this multiplies compilation time by 50. At this point the compilation already took 2 minutes on a local computer and 12 minutes on our Hudson server.
  This is not so relevant while developing due to the fantastic development mode but it contradicts our concept of executing a compilation on Magnolia module installation/update. Possible workarounds are: use a draft compilation first or compile permutation on demand but it seems like a mine field.
• MVP pattern. As recommended we wanted to apply the MVP pattern but ExtGWT has its own concept of handling events and this conflicts with the proposed approach by Google. The goal is that the presenter layer can be tested with normal JUnit test cases without extending GWTTestCase which runs a browser under the hood and is terribly slow. We could wrap the ExtGWT components but this won't lead to a slim architecture design and to billion of interfaces.

So we dropped ExtGWT and designed a plain GWT approach:

• Use gwt-exporter to expose a plugin mechanism
• Use GWT 2.1 which brings a new MVP framework (at the time milestone 2 release)
  
• Write our own widgets or write a wrapper for few components
  

It is not surprising that we brought the ExtJs/Javascript approach back on the table at that point. Once this happened the Vaadin supporters realized their chance and raised their hands. While I never liked the server side part of Vaadin and excluded it from earlier evaluation phases for that reason, I was desperate enough to reconsider that decision ;-)

We launched a survey and filled a decision table.

Survey

None of the approaches won the survey but the Vaadin community got attracted and this lead to same phone calls with Joonas Lehtinen, the CEO of IT Mill - the company behind Vaadin. So we realized that there is potential for collaboration for the two communities and companies.

Decision Table
We dropped the ExtJs/Javascript for the simple reason that we didn't have enough motivation and knowledge to go for it. Some think we are lame but have you ever tried to make a cool product with an unmotivated team which in addition lacks the skills to fulfill the task? I hope not.
While Vaadin got the most points (39 points), GWT (29 points) was not yet dismissed as the decision table was only meant to give us an overview and we have not weighted the criteria.
So we ended up with having the two valuable options:

• Plain GWT
• Vaadin

Team Voting
At the end we had a final voting in the team. The result was 4 against 2 in favor of Vaadin.

So that was it: Vaadin

Reasoning
In the next blog post - following today - I will explain why Vaadin was the prize winner and how it solves some of the bigger problems we faced with the plain GWT approach.