The Ultimate Web UI Framework
After doing some research I've found a couple of candidates:
- Echo2
- Google Web Toolkit (GWT) with the GWT-Ext components library
- JBoss RichFaces (it is based JSF; perhaps use with Seam)
- OpenLaszlo/Flex
- Others: Wicket, Grails, Struts 2, ...
- Client-side versus server-side interaction handling
- Does the presentation logic that controlls user interaction and UI changes run on the client and only sends/receives data when it's necessary or does the presentation logic run on the server-side with (nearly) each action of the user resulting in a request?
- Implementation language: Java, XML+JavaScript, html/css/js, other
- Is the interface described using the classical combination of JSP, HTML, CSS and Javascript, or is it described in pure Java, or does it use the combination of XML and JavaScript, or even something else?
- Interaction model: event-based or request-driven
- And so on...
Regarding the frameworks, which I'll describe later on, we can say:
- Client-side: GWT and OpenLaszlo or Flex run mainly on the client while the others more on the server
- Language: With GWT & Echo you define your UI in pure Java, with Flex/OpenLaszlo in xml+js, JSF uses the classical JSP & co. combination.
Introducing the frameworks
Disclaimer: I'm no master of these frameworks. The information below is a compilation of opinions of their users and info from various sources like documentation, articles and blogs.
All of these frameworks are open-source.
Echo 2 (demo)
- UI defined by Java classes as with Swing, event-based
- runs on the server-side and most user actions result in a request being sent to the server
- commercial IDE for - I suppose - graphical design of the UI; but you can code it without that in any editor
Pros
- UI defined in Java
- => you don't need to spend weeks learning JSP, JSTL, custom taglibs, HTML, CSS, JavaScript. This makes also developers cheaper.
- => support for refactoring
Cons
- Runs mainly on the server-side, many user actions result in a request, which makes it slower and less responsive. For example switching a tab in the demo took usually around a second (this may be given by the current load, limits etc.of the server, but frameworks that handle this completely on the client side don't have any such problems)
- the Eclipse-based EchoStudio 2 IDE for rapid visual development of Echo 2 UI is commercial though you can, of course, code your ui by hand in any editor
- A new API to learn - it could be perhaps more similar to Swing API to make it easier for newcomers
Google Web Toolkit (GWT) with GWT-Ext components
As with Echo 2, you create your UI by writing Java classes, using a Swing-like API. But here the UI components (widgets) you've written are compiled at the development-time into html/css/javascript.
Pros
- Pure Java development => less knowledge required, support for refactoring - as with Echo 2
- The components (widgets) are pure html/css/javascript and can be embedded into any page, even a static one or one created via another framework (you could e.g. place the component on a JSF page)
- Runs on the client-side - a GWT application is a true rich UI running in the user's browser, the presentation flow and user interaction is handled locally as much as possible. The server-side is only called when data interchange in necessary.
- Backed by Google; no need to say more :)
- Steap learning curve - according to some you can start writing reasonable GWT applications in a week
- A rich and growing set of components provided within GWT-Ext
- Debugging: You can run the UI in a hosted mode within a special browser provided by Google without compilation into html/..., thus being able to use Java debugger etc. for it
Cons
- Java: provides only a subset of java.lang and java.util. Currently only works with Java 1.4, the upcomming GWT 1.5 will only work with Java 5.0..
- Closed-source Java to html/css/js converter
- All the application files are donwloaded at once to the client, which can make its start slower; on the other hand Google is very good in optimizing the file sizes and the generated code from the donwload time perspective.
- According to some people it isn't a good idea to have all the presentation logic on the client side for security reasons
JBoss Rich Faces (for JSF)
RichFaces is a JavaServer Faces (JSF) component library that heavily uses Ajax. But it goes beyond that and makes it possible to add Ajax support to existing components/applications, provides skinnable components, makes it possible to pack .js and .css into JAR archives together with your components.
JSF is "the standard", component and event-oriented presentation framework. To get the maximum out of it, you can use RichFaces together with Facelets (see my Facelets post) and the application framework JBoss Seam, which provides among others integration with EJB, business processes, and the "conversation context".
Pros
- Builds on JSF, the "new" standard (JSR #127, v.1.2 #257, the new v.2.0 #314) for creating web UI and pluggable components. JSF can be also used for creating portlets (see JSR #301 - Portlet Bridge Specification for JavaServer Faces) though I don't know how much is this supported by RichFaces itself
- RichFaces components and Ajax-support can be easily added to existing JSF applications and pages
Cons
- Runs on the server-side, most user actions result in a request, either via GET/POST or in the background via ajax.
- It carries all the disadvantages of JSF (search on the web...)
- You need to know JSF, html, css and either Facelets or JSP, JSTL etc.
OpenLaszlo or Flex
Both these tools/frameworks let you create rich UI in Flash (or also DHTML with O.L.) using XML and JavaScript and both have no relation to Java - they provide for creating rich client-side applications that communicate to the server-side using some standard mechanism, for example web services or RESTful servlets returning xml or json.
OpenLaszlo 4.x has the advantage of being able to compile the UI not only into Flash but also into DHTML (html/css/javascript). See OpenLaszlo demos.
Adobe Flex is development framework for creating rich Internet applications using variations of XML (MXML) and JavaScript (ActionScript). The Flex SDK is open-source, the Eclipse-based Flex Builder IDE for rapid development of Flex applications is commercial. The famous author of Thinking in Java, Bruce Eckel, promotes Flex and mentiones OpenLaszlo (recommended reading!; check also the comments).
Pros
- Very rich UI with advanced capabilites regarding e.g. multimedia and vector graphics
- Runs on the client side and only contacts the serer-side when necessary to get or send data
- You only need to learn the framework's xml and javascript, not the full stack of jsp/jstl/css/....
- Can use back-ends not written in Java => encourages writting you server-side components in such a way that they can be used and reused in multiple ways. Because it isn't bound to any particular server-side framework or language, you can you is with any you like.
- There is a fair number of existing components for both Flex and OpenLaszlo (especial ly for Flex)
- Flex is faster and richer than OpenLaszlo
- You can nest Flex application into a page and integrate with it
Cons
- You need Flash plugin in the browser to use the UIs. OpenLaszlo can generate dhtml, but I'm not sure whether it's mature enough.
- The startup may be a bit slower
- Flesh isn't HTML and thus search engines like Google cannot search and index it so well
- an IDE with visual UI builder and other support either isn't available or only for a fee (though people say you don't really need one)
- Flex isn't completely free: is some cases, like using Flex Data Services on multiple CPUs, you must pay (but see the LGPL Granite DS)
Others: Wicket, Grails, Struts 2, ...
There are certainly other popular frameworks that may support rich user interface. But I've deliberately limited myself to the most famous ones and those that are somehow unique and catched my attention.
Criteria for evaluating web UI frameworks (draft)
The following criteria could/should be used when deciding wheher a particular framework is suitable for an application and the problem it tries to solve.
Practical
- availability of developers familiar with the framework
- tools support
- existing components
Learning & using
- support community
- learning curve
- documentation
- rapid development: can write UI fast?
- ease of use - principles like DRY, convention over configuration etc. that make it's use easier
- flexibility (let me do st. unexpected that I really need)
- performance, scalability
- maintainability; refactoring supported?
- suitable for large enterprise apps with many "pages"?
- user experience (rich <> ajax)
Other
- evolution: has it momentum? new versions backward compatible?
- stable and proven framework?
Note: diffferent frameworks are suitable for different cases; there is no single framework that's the best fit for any problem. Still we would certainly like to keep the number of frameworks used as small as possible.
Summary/Conclusion
I was searching for a framework that would allow me to create rich user interfaces that are very interactive and responsive and don't load the server too much. After examining some favourite frameworks I've decided for a few that I'd like to try.
Different applications have different architectural and UI requirements, which makes some frameworks suitable for the problem at hand and some not. But when we limit ourselves to a user-interaction centered application, I think that the classical frameworks like Struts 1/2 and JSF just aren't suitable, even with Ajax. They place to much burden on the server, aren't responsive and interactive enough and don't always provide for rapid creation of rich interfaces. I like the idea of user interface running on the client, as with GWT or OpenLaszlo, and having only the business logic on the server-side. This provides for richer and more responsive UI and places less burden on the server, which can thus serve more clients. Ganesh Prasad promotes such a solution in his blog entry "Life above the Service Tier" with the term Service-Oriented Front-End Architecture (SOFEA), a rich UI above a service layer. I indeed recommend reading it.
To conclude: I'd use either GWT or OpenLaszlo (or maybe Flex) when a true rich user interface is required and/or when this of technology and approaches isn't against internal standards of the company. If a more traditional approach is necessary, I'd prefer RichFaces because JSF is quite popular and standard.
Links and resources
- Adobe AIR (former Apollo) - runtime for running web 2.0 and Flex applications as desktop application, with full integration, access, and support for running offline.
- Google Gears - "an open source browser extension that enables web applications to provide offline functionality" by providing JavaScript API for storing & serving resources (html, images...) locally, acess to an embedded database, and more.
- Microsoft Silverlight - multiplatform and multibrowser plugin and runtime for running rich .NET applications from within a browser. It competes with Flesh (hence Flex) and the new mysterious Sun's JavaFX.
Articles, blogs etc.
- Matt Raible: Comparing Web Frameworks: Time for a Change? - "top 6 frameworks" and an enlightening discussion.
Comparing JVM Web Frameworks Presentation (Nov 14, 2007) - Comparing the Google Web Toolkit to Echo2 - by a developer of Echo
- James Ward arguments why to use Flex in a comment to Raible's Comparing JVM Web Frameworks
- ... and many more ...
- James Gosling on Adobe Flash / Flex / AIR
- Thinking of alternatives to GWT-RPC - e.g. Jaxter, Enunciat
- James Ward arguments why to use Flex in a comment to Raible's Comparing JVM Web Frameworks
- 2008-04-01: Sajnvi Jivan: Thoughts on Java web frameworks and RIA - recommends Flex&GWT for dynamic apps and request-response frameworks for those needing SEO, bookmarkability, and RESTful services
- Blog Evolutionary Goo: Choosing a Java Web Framework (Revisited) (2008-09-18)