Architecture Survey

We would like to get feedback on the three proposed solutions for the Magnolia 5.0 architecture. So we created a survey to consult the community/partners/employees.

Survey: 5/6. August (Do/Fr)
Decision: 9. August (Mo)

Note: We are not considering any alternative solution other than the three proposed here and don't want to open again a bigger discussion about that topic.

Proposals

A) Plain GWT (2.1)

• use plain GWT/Spring Roo (GWT 2.1)
• write the missing widgets or write adaptors for some of the missing widgets
• no ExtGWT/GXT (seems to be to heavy and isn't as active as ExtJs)

pro/contra
responsive UI
more freedom: look and feel, ..
use the REST services we expose on the server
more custom development
2.1 is currently only milestone 2

B) Vaadin

pro/contra
rapid development (don't have to think much about protocol, architecture)
easy to use/learn for Java developers (excellent documentation)
no GWT compilation (unless the module adds a custom widget which is more than a composite of standard widgets)
server side event handling (more requests and serverside execution but giving the possibility to use plain Magnolia classes instead of DTOs)
state in the session

C) ExtJs/Javascript

pro/contra
plain and straight, no fancy framework
tooling (testing, no javadoc, ..)
team motivation/knowledge
license

Results

Thanks for voting! Each of the proposed solutions had its supporters and none is the clear prizewinner and none was thrown out. While Vaadin got the most votes we think that some promoters weren't Magnolia users but Vaadin community members.

It is interesting to see that most of the voters have experience in the technology they voted for or at least plan to use it in the future.

Decision Table

We here at Magnolia Ltd filled out a decision table in the meanwhile. Again it was Vaadin which won. The javascript/ExtJs approach were overruled less because it is a bad approach than that the team lacks experience and motivation for it.

Interesting comments

Most enlightening were the given comments. Following some excerpts

GWT

pro:

You should probably consider the good tooling support - GWTDesigner for GWT in your evaluation. With recent acquisition of Instantiations by Google the tooling support is bound to improve.

Also you need to factor in the ease of debugging across different frameworks. This could possibly encourage development of sophisticated UIs.

We use GXT/Ext GWT over here, and have quiet good experiences using it.

Wow, Magnolia the first GWT CMS, I'm a bit excited

Already having several GWT projects integrated into Magnolia

We made good experiences using GWT in the admin interface. Using Java for developing complex functional UIs gave us a boost in productivity, and resulted in a high-performant and highly usable interface.

Vaadin
pro:

Would aid rapid devlopment, and I would rather we had Magnolia 5.0 sooner than spend a long time cranking out user interface code. We should still create the REST layer, but have a separate module to interface between Vaadin and the Web Service calls. This would allow the UI to be changed later if we do find limitations, without any change to the back-end.

contra:

Vaadin's server side session management does not appear too scalable for high traffic websites. Based on my experience, I tend to favor decoupled stateless interactions between browser and the app server as it (at least) reduces the overhead of server-side state management, thereby increasing scalability. Besides, the value addition of Vaadin is not that great considering the cost - vendor lock-in, lesser maturity. But that could just be my opinion.

ExtJs
pro:

We used ExtJS/Javascript on a major closed source project here and found the following:

• Once understood our developers became VERY productive on the frontend.

• ExtJS has the most consistent look and feel and programming API of any JS UI framework we have worked with. The consistent programming API was a big help.

• ExtJS API documentation is very good for programmers.

• ExtJS general quality is pretty good. We ran into some problems but for the most part were able to overcome with help from the ExtJS community.

As a Magnolia user, Java Developer and ExtJS (now Sencha) developer, I would advocate the use of ExtJS and plain JavaScript for maximum flexibility. ExtJS has a steeper learning curve, but once you establish a framework for the project, you'll find that the ability to reuse components is quite easy to do. Also the UI is really polished and makes for impressive demos.

During the past years I increased my experience in Javascript. I don't like Javascript since I started coding but it is a MUST. As me, many other people have the same experience, so I think that the gap to start using Magnolia 5.0 should be little. A change of technology can be an improvement on a stable architecture.

contra:

ExtJS/Javascript could be good if you are developing lot of custom snippets. But over time this can grow up to be a maintenance overhead (sooner or later).

Misc

It's most important that the Java code behind the UI is written in an extensible manner. Any part of the Magnolia interface may require bespoke customisation for a client and the ease/portability with which these customisations are created depends on the underlying codebase.

I know it's a different decision, but I'd really love to see Magnolia 5 using Sling