Advantages vs. AJAX

Three key advantages of ULC vis-a-vis AJAX:

ULC is far more cost effective than AJAX and is ready for mission-critical applications that have a large and complex UI. To be fair, we want to point out that AJAX has an advantage over ULC: AJAX 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 AJAX

Diagram comparing architectures of ULC and AJAX

Functionally Rich, Mature and

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 therefore means that

Functionally Poor, Immature and Proprietary

The UI components of AJAX libraries are rudimentary compared to those of Swing, and at the very beginning of both their development cycle and market shakeout. 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.
  • 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

AJAX libraries are a mixture of technologies with multiple languages, including Java, HTML, DHTML, JavaScript, CSS, proprietary XML languages, and more. Choosing such a library 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.

Server-side Architecture

Both the programming model and the execution model of ULC are server-side. Applications are installed and executed on the server. The client executes a compiled Presentation Engine that is independent of individual applications. As a consequence,

Complex Distributed Architecture

AJAX libraries vary widely regarding their programming model and execution model. The source code for the rich UI is downloaded to the client at run-time and executed there, possibly together with business logic. As a consequence,

  • the developer is alleviated from the difficult issue of distributing logic between client and server.
  • the developer typically has to distribute logic between client and server, which is expensive and error-prone.
  • applications are easy to scale up for thousands of users, because client/server interaction is built-in and highly optimized.
  • applications are often difficult to scale up, because client/server interaction typically has to be optimized for each application.
  • applications are easy to protect against security attacks, because the client is compiled and executes no business logic.
  • applications are difficult to protect against security attacks, because the architecture allows executing any kind of code on the client.