| french | english |
 |
|
| Sign in | |
| 13-10-11 / 22:52 : Vaadin : still way behind Cappuccino (cjed) |
| The recent Vaadin framework, that has been developed for at least one year (however far later than Cappuccino) brings application navigation/logic on the server side (en Java), by limiting json messages to widgets (GWT) state changes. Moreover, as the communication layer is generic (common, many bridges still available), GWT's Java to Javascript generation step isn't required anymore while developing (contrary to ExtGWT and Smart GWT). However this solution still does not catch up with Cappuccino in practical use, both in terms of achieved result, performance, and concepts : - Interest of Java on the server side is less obvious for navigation application code (only UI management and actions). Using Javascript is sufficient for these, and Java is more useful at services layer (more complex, connectors to heterogeneous systems). - Defining the user interface is based on Swing syntax and principles, that is very limited use of design patterns, and not in the elegant manner found in AppKit (responsability chain, dynamic bindings, KVC, KVO, delegates instead inheritance). There is no real/elegant architecture, nor innovative. The provided features are limited to widgets, whereas AppKit adresses most of applications needs, thanks to proven best practices. - Such a solution to generate Cappuccino client side would be long and not fun, as it would require to define Java wrappers/generators for each control. Moreover as previously said the AppKit is more than just a widgets library. This redondancy would also be unuseful, as client side service proxy (using CP2JavaWS) seems comfortable for agile development. - Objective-J 2.0 will bring a modern parser, and WebKit still allows powerful and easy debugging. Validating using Java compilation doesn't seem so great, besides adding weight/complexity. Moreover state changes and/or display bugs would still require digging into generated Javascript code (despite it being simpler since most of navigation/application has been moved on the server side). - Some controls (notably Table view) are limited in Vaadin. Most importantly, performances look really behind : while live scrolling, it takes many seconds to update the rows. The developers choosed then to display a waiting message (range of rows being loaded - however not accurate). Cappuccino and CP2JavaWS allow live scrolling among thousands of rows without any pause (on WebKit), or really slight ones using Firefox. The lite client side application code in Vaadin may require more messaging with the server (the client side is less autonomous - probably no caching in table view, etc.), that might lead to this performance concern. - Vaadin does not provide abstraction for media layer, contrary to Cappuccino's implementations of Quartz/CoreAnimation above its DocumentBridge. - provided layouts arent's as evolved as the constraint based one from Cappuccino (with automatic recursive calculation). -the interface builder, whose design is derived from Atlas/IB, faces same limitations as other common editors (as they do not follow the principles that did make IB great) - the default theme, despite being (too much) derived from Aristo, isn't as polished. We just can compare Vaadin Tunes with ThatMusicApp. Recent buyout of Sofa (that created Aristo) by Facebook tends to confirm their advance. Even Google didn't try to compete in this area, where they have always been known to be weak. |
| Comments |
| Write a comment |