Advantages vs. JSF / Struts

Three key advantages of ULC applications vis-a-vis HTML applications that are based on JSF and/or Struts.

ULC is far more cost effective than HTML/JSF/Struts. To be fair, we want to point out that HTML has an advantage over ULC: HTML applications can potentially be used in any browser, while ULC applications require that Java is installed on the client, either as a plug-in within a browser, or on the desktop.

ULC compared to JSF

Diagram comparing architectures of ULC and JSF / Struts


Functionally Rich, Mature and Standardized

ULC uses the Swing UI components of the J2SE standard. Swing's components are functionally very rich, mature and proven in thousands of applications. ULC itself is proven in dozens of large mission critical applications and by thousands of users. Choosing ULC means that

Functionally Basic, Immature and Proprietary

The UI components of JSF and STruts are basic compared to those of Swing. They are being challenged by AJAX libraries and evolving rapidly, partially towards AJAX. Choosing such a library means that

  • you profit from Swing's comprehensive standard widget set as well as an established market of third-party component libraries based on Swing.
  • you have to develop numerous add-ons yourself because the library will offer nothing beyond the most simple components.
  • you can expect that Swing and ULC evolve slowly - because they are functionally very complete - and that they will be supported for years to come.
  • you have to expect that the library evolves rapidly, or that it will be eliminated from the market by one of the numerous contenders.
  • you profit from the fact that ULC supports multiple Java Runtime Environments (JREs), and that JREs are much more standardized across platforms than JavaScript implementations.
  • you will suffer from the subtle differences between the implementations of JavaScript across browsers.
  • you have the choice between developing a full-fledged desktop UI with multiple windows, or to stay within the interaction paradigm imposed by web browsers.
  • you are limited to the page-oriented interaction paradigm imposed by web browsers.
  • in a worst case scenario, where Canoo goes out of the market, you will be left with lean and well-structured pure Java code that can be maintained easily by any developer who knows Swing.
  • in a worst case scenario, where the provider goes out of the market, you will be left with an enormous stack of proprietary software, implemented with a heterogeneous mixture of technologies.

Single Technology

ULC is a lean Java library that relies on a single technology and language. It delegates functions to the JEE and JSE standards wherever possible. Choosing ULC means that

Complex Technology Mix

JSF and Struts rely on a mixture of technologies with multiple languages, including Java, HTML, DHTML, JavaScript, CSS, proprietary XML languages, and more. Choosing JSF and/or Struts means that

  • Java skills are the only requirement for development.
  • you need a complex and proprietary set of skills for development.
  • any Java IDE is fine for development.
  • likewise, you need a complex and proprietary set of tools.
  • debugging and testing is simple because the developer stays within a single technology and IDE.
  • debugging and testing is a nightmare because of syntactic and semantic breaches between technologies, and the overall complexity.

Minimal Network Traffic

Network traffic of ULC applications is minimal, at least 10 times more efficient than for HTML applications. Choosing ULC means that you will get outstanding performance, even over slow modem lines and over networks with miserable latency.

The reason for ULC's efficiency regarding network traffic is that client/server interaction works on the level of widgets rather than pages. This means that

Massive Network Traffic

JSF and Struts generate massive network traffic. Bandwidth requirements and network latency are often a major challenge. Choosing JSF and/or Struts means that slow network connections and latency will pose a major problem.

The reason for the inefficiency of JSF and Struts regarding network traffic is that client/server interaction works on the level of pages rather than widgets. This means that

  • user actions update individual widgets, which generates minimal data transfer
  • .
  • user actions update entire browser pages, which results in substantial data transfer.
  • user actions can be handled asychronously, such that the UI is not blocked during server roundtrips. This enables server-side processing of user input while the user continues working.
  • user actions must be handled synchronously, such that the UI is blocked during server roundtrips. This leads to inefficient action-wait/reload-cycles.
  • widgets like tables and lists only load visible elements from the server to the client (lazy loading). As a result, such widgets can handle thousands or millions of elements efficiently.
  • widgets like tables and lists must be split up into pages. As a result, such widgets are unable to handle large amounts of elements efficiently.