One of my customers recently asked me to help them choosing a framework for developing rich web applications, i.e. desktop-like web applications (see also my previous article
[1]). After some internal discussion, it was decided to short list
Google Web Toolkit (or GWT) and
Adobe Flex.
Microsoft Silverlight was not included for a number of specific reasons, like market share and coding culture. Moreover, the customer also asked to include
jQuery in the study, even though it's not a complete framework (jQuery was already used by the customer, and the department had to justify the introduction of a new technology).
Note that the comparison that follows was done taking into account some specificities of the customer. A different context might lead to different conclusions. (There is no one-size-fit-all in the landscape of RIA frameworks.)
I took into account the latest versions of the frameworks at the time of this writing, i.e. GWT 2.2.0, WindowBuilder Pro / GWT Designer 0.9.0/2.2.0, Flex 4, Flash Builder 4 Premium Edition, (?BlazeDS 4?).
Criteria
Based on the typology I had established previously (
[1]), I prepared the following list of criteria:
- Staffing
- Availability of programming skills
- Learning curve
- Documentation and Tutorials, Books
- Productivity
- GUI Builder
- Object Mapping
- Validation
- I18n and L10n
- Industrialisation (automatic builds, tests...)
- Maintainability
- Design patterns (MVC or MVP, IoC/DI...)
- Testability
- Programming language (static typed vs. dynamic typed, e.g. Java vs. JavaScript)
- Risk (durability of the vendor)
After reading a number of references (
[2]...
[6]), I completed with a few additional criteria:
- Staffing and Support
- Productivity
- Data Binding
- Widgets/components library
- IDE support
- Communication protocols and formats (REST, SOAP)
(Communication formats (JSON, XML...) are discussed in the "Object mapping" criterion.)
- Maintainability
- Declarative UI design
- Style sheet
- Scalability (avoid server-side session)
- Browsers versions coverage
- Security
- User experience
- Mobile platforms support
- Client side drawing
- Printing
- Drag and drop
- DOM (browser) integration
- Stability
jQuery
While GWT or Flex are complete frameworks, jQuery is only a Javascript library providing additional widgets and functions (events, interactions, effects) to the developer. It does not solve the maintainability issues of Javascript based web page design (no, or weak, design patterns, dynamically typed language, no declarative UI design, poor testability, no IDE support...). The productivity is also questionable, since there is no support for mapping objects to server resources, validating object attributes, or for internationalisation. For these reasons, we must consider jQuery more as a tool for improving the interactivity of a web page, not as an appropriate tool for building desktop like applications in an enterprise context (see
[1] for the differences between a rich web application and a set of interactive web pages).
Comparisons
We here compare GWT and Flex through each set of criteria: staffing, productivity, maintainability, user experience.
Each criteria receives a mark between -- and ++ (- and -- for bad performance, + and ++ for good performance).
Since there are a lot of add-ons available in the respective communities, we've indicated with the special mark "opt." the criteria where there is support which is not native.
A "!" mark indicates a compatibility issue between some criteria.
Staffing and Support
The staffing and support criteria compare as follows:
| Criteria | GWT | Flex |
|---|
| Availability of programming skills | ++ | + |
|---|
| Learning curve | ++ | + |
|---|
| Documentation and Tutorials, Books | ++ | ++ |
|---|
| Community | ++ | ++ |
|---|
Skills. Being 100% Java based, GWT has an advantage over Flex, where the client side application is built using a dedicated language (ActionScript), unique to Flash. Even though Flex skills are relatively common, ActionScript developers are clearly outnumbered by Java developers. This is even more significant for a company that is already using Java as his prime technology, since it already has inside resources that do not need to learn a new language.
Learning. Developing GWT based application is very similar to developing actual Java based applications, and the programming model is very similar to the one of Swing based applications. Hence, traditional Java developers won't be disoriented. Flex is reported as being quite easy to learn for web developers (partly because ActionScript is based on JavaScript), but won't be on par with GWT for existing Java developers.
Documentation, Communities. Both solutions have very large communities communicating on-line, one can easily find numerous tutorials on the web, and there are plenty of books available. The online communities also provide plenty of add-ons for both framework. (This is particularly useful for GWT, for complementing lack of native capabilities.)
Productivity
The productivity criteria compare as follows:
| Criteria | GWT | Flex |
|---|
| GUI Builder | +! | ++ |
|---|
| Object Mapping (JSON, XML...) | -/opt. | ++ |
|---|
| Data Binding | +! | ++ |
|---|
| Validation | - | + |
|---|
| I18n and L10n | + | + |
|---|
| Industrialisation (automatic builds, tests...) | ++ | ++ |
|---|
| Widgets/components library | opt. | ++ |
|---|
| IDE support | ++ | ++ |
|---|
| Communication protocols and formats (REST, SOAP...) | -, opt. | ++ |
|---|
GUI Builder. Google recently acquired the company "Instantiations" and is now delivering one of their product, "GWT Designer", together with the GWT framework. This is a full fledged GUI builder. However, since the acquisition is quite recent, both technologies are not yet fully integrated. Noticeably, it's difficult (if possible!) to use the "GWT Designer" with a declarative UI approach (see "UIBinder" further).
Object mapping. Object mapping is automatic when using GWR RPC for communicating with the server. When using other protocols, it will depend on the data format. For JSON, the mapping is obviously automatic to JavaScript, but one has to manually map the JavaScript to Java. When using XML, the mapping
and the parsing must be completely done manually (or you'll have to rely to a third party module). For Flex, mapping is trivial since JSON and XML are native data types.
Data binding. In GWT, the "Editor" framework makes possible to do data binding. It must be configured programmatically (Java code) and relies on the declarative UI mechanism (UIBinder) (see further for impact of using UIBinder). In Flex, the data binding mechanism is available both in the declarative UI (MSXML) and programmatically (ActionScript).
Data validation. In GWT validation must be programmed manually, or through a third-party add-on providing JSR 303 validation (though there is immature (partial, unstable) JSR 303 support in native GWT). Advantage of JSR 303 would be that you could reuse the same code on the server. Client side data validation is done in Flex using "Validators". They are available both in the the declarative UI (MSXML) and programmatically (ActionScript). A number of predefined validators are provided and custom validators can also be defined.
I18n and L10n. GWT manages localisation with resource files. There is also a specific mechanism helping generating these files from the declarative UI (UIBinder) files. Flex does support localised strings through ResourceManager.
Industrialisation. A GWT app can also be compiled from command line, or even through a 3rd party Maven plugin. Only the premium edition of Flash Builder provides Ant based build and unit tests (hence also command line) capability for Flex. Maven support is only possible through third party plugin.
Widgets library. Standard GWT widgets are quite basic, though lots of third party add-ons provide very rich libraries. Standard Flex widgets library is already very complete.
IDE support. GWT comes with a plugin for Eclipse (free), providing a.o. a unit test framework, an emulation mode to simulate the behavior of the browser, text completion for JavaScript and UI design file... Flex has its own commercial IDE, Flash Builder (either as an Eclipse plugin, or as a standalone Eclipse based application) providing also text completion, refactoring... The premium version of Flash Builder comes with "testing tools such as profilers, network monitoring, an automated testing framework, integration with Flex unit testing, and command-line build support (...)".
Communication. REST communication is possible from GWT by constructing HTTP requests. The framework provide no facility to automatically bind a data object to a REST service. SOAP is not possible without third-party add-on. Hopefully, GWT also provides a proprietary protocol (GTW RPC) that provides automatic binding. Flex provides support for both SOAP and REST-like protocols, as well as a proprietary protocol (AMF). All can be used either from the declarative UI or from the code. There is also a mechanism for managing
remote data objects.
Maintainability
The maintainability criteria compare as follows:
| Criteria | GWT | Flex |
|---|
| Design patterns (MVC or MVP, IoC/DI...) | ++, opt. | +(+), + |
|---|
| Testability | ++ | ++ |
|---|
| Programming language (static typed vs. dynamic typed, e.g. Java vs. JavaScript) | ++ | + |
|---|
| Risk (durability of the vendor) | ++ | + |
|---|
| Declarative UI design | +! | ++ |
|---|
| Style sheet | + | ++ |
|---|
| Scalability (avoid server-side session) | ++ | ++ |
|---|
| Browsers versions coverage | + | ++ |
|---|
| Security | - | - |
|---|
Design patterns. GWT recommends using the MVP design pattern. The GIN Google add-on brings to GWT dependency injection based on JSR330. Flex uses the MVC design pattern and it uses a dependency injection mechanism in the declarative UI files. [?Event bus?]
Tests. GWT can be tested using JUnit. There is a test container making possible to run unit tests without starting the whole UI. There is also a "development" mode in the Eclipse plugin that makes possible to run the whole UI in the browser without compiling the code (which is very slow!). GWT can also benefit from all existing Java libraries (like Hamcrest, FEST, jMockit, Mockito...) for writing unit tests. Adobe provides FlexUnit 4, a framework similar to JUnit. It also provides a UI test container (UIImpersonator).
Language. GWT is based on (a subset of) Java, which is statically typed .Flex uses ActionScript (see
[10]), based on JavaScript, which is not statically typed, but there is an option of the compiler that enables strict type checking. Besides this, ActionScript has more OO features than standard JavaScript.
Vendors. Both vendors (Google and Adobe) are well established. Though Adobe, being a smaller player, is more subject to buyout. Another hand, Google is not a software house, and nothing guarantees it will keep the focus on GWT, though it is a strategic product for Google.
Declarative UI. GWT: UIBinder (compatibility with GWt Designer?). For Flex, the MSXML UI declarative language is at the base of the framework and is directly edited by the WYSIWYG editor in Flash Builder.
Styling. Both frameworks support CSS. The version of CSS supported by GWT will depend on the target browser and this can be tedious in case you target a multi-browser environment. Flex not only has support for CSS at various levels in the UI, but also for themes (packaged style sheets and assets).
Scalability. Both frameworks enable building a RIA where the whole UI context is maintained on the client side, hence enabling session-less server-side code.
Coverage. GWT supports all major browsers. It does this without performance impact because it generate separate sets of resource for each "kind" of client (a "kind" of client being a permutation of browser family and language). Note that there is always a risk of having to recompile an application when a new browser appears, in case it's not fully compatible with older browsers. Flex is completely independent from the browser, since it runs in a separate plugin.
Security. The level of protection of an application built with GWT cannot be better than what is provided by the web browser. In that respect, a GWT application is neither worse nor better than a traditional web application, being subject to all traditional web exploits (like cross-site scripting...) The Flash player has a SandBox mechanism to isolate an application and avoid malicious attacks to the client side code, however it has not proven to be very robust. (Most recently known exploit have been patched last month only!)
(Has an illustration, in 2010, for Windows, the site secuser.com reported 10 critical vulnerabilities for Internet Explorer and 7 for Flash (+ 1 medium). During the same period, only 3 critical vulnerabilities were reported for Java.)
User experience
The user experience criteria compare as follows:
| Criteria | GWT | Flex |
|---|
| Mobile platforms support | ++ | + |
|---|
| Client side drawing | exp./opt. | ++ |
|---|
| Printing | - | + |
|---|
| Drag and drop | opt. | ++ |
|---|
| DOM (browser) integration | ++ | ++ |
|---|
| Stability | ++ | - |
|---|
Mobile platforms. Since a GWT application runs in a web browser, it can target any platform with a web browser (provided that it supports JavaScript). This is the case for all modern smartphones. Moreover, with the advent of HTML5 in Android, iOS, and RIM phones, the capabilities of applications running in the browser will be even closer to native apps. On the other hand, Flex is now supported by most smartphones manufacturers except one, but which is not the least since it's Apple.
Drawing. Client side drawing is only an experimental feature in GWT (at least until 2.2) and it uses HTML5 Canvas (hence requires a compatible browser). There are also third-party libraries providing drawing capabilities for any browser. Drawing capability is native in Flex, and is very powerful, being the Flash inheritance.
Printing. GWT provides access to the browser "Print" command. Printing a specific item requires to render it first in a separate window or frame. Flex has a built-in API for controlling a printer. This API enables printing any "Sprite" (a displayable component).
Drag and drop. Drag and drop support is provided has a third party library in GWT. It is native in Flex.
Browser integration. Integration of GWT in the browser is de facto. For Flex, communication with the browser is possible through JavaScript code. Both GWT and Flex have support for
deep linking (linking directly on a specific view of the application) and
browser history mechanism (Back and Forward). GWT does this through "History Tokens" mechanism, and Flex through javascript ("history" resources) and BrowserManager class.
Stability. Flash has sometimes be reported to present stability issues due to memory management. Moreover, since it requires a plug-in, Flex has a negative impact on memory per se. It is also to be noted that some Flash implementations (typically on Mac OS) had known dramatic CPU performance impact in some situations. This has only be fixed in recent versions of the Flash player.
Other considerations
BlazeDS... an open source server side framework from Adobe to ease integration of Flex with the application server, data, and other web services.
HTML5... likely the platform of the future. Will be natively supported by GWT. On another hand, Adobe has recently shown effort to support it also transparently from Flex projects.
Multimedia (video, web cam...)... are supported by Flex. GWT support is limited to web enablement (cf. also recent HTML5 progresses).
Summary
GWT: There are more skilled people, ad there is a better browser integration. Lot's of missing capabilities are possible only through third-party add-on, for which there is no guarantee of longevity.
Flex: It's more complete, has better productivity and better user experience. Capabilities for communication, object mapping, and data validation are very good. There might be a performance impact.
Both share the low security profile of any web based application.
Recommendation Given the specificities and needs of my customer, based on the above advantages, and on the opinion of both developers and customer architect, I recommended the selection of Flex.
References
.jpeg)
Ce qui m'a fait revenir au jeu, c'est la découverte du magazine "Jeux et Stratégie". Directement j'ai été séduit. Je dévorais chaque numéro, puis attendais avec impatience le numéro suivant. Nous sommes dans la seconde moitié des années '80, et à cette époque ont voit les premières prémisses du jeu de société moderne. Je joue alors, notamment, à "Fief", et "Armada". "Jeux et Stratégie" m'aura fait découvrir aussi le jeu de rôle, qui vont prendre le pas sur le jeu de société pendant un long moment. Parallèlement, mon investissement dans un mouvement de jeunes me conduit à organiser de nombreux jeux en plein air, déjà influencés par mon attrait pour le jeu de société et le jeu de rôle.
Après quelques années de vie professionnelle, je suis initié au jeu de rôle grandeur nature. Je m'investis à fond dans cette activité et devient vite organisateur dans mon club (scénarisation, écriture de rôles, conception de système de règles), pour ensuite participer à la création de la fédération belge. En parallèle, je masterise "Donjons & Dragon 3e édition" dans les "Terres Balafrées". Je fais peu de jeu de société à l'époque, mais j'ai tout de même le temps de découvrir les "Colons de Catane" et "Elixir", puis plus tard aussi "Batt'l Kha'os", dont l'auteur est un bon copain rencontré en grandeur nature.
Posts
