Thursday, August 19, 2010

GUI Development

A review of implementation and deployment strategies for GUI applications

The overall GUI implementation space:

  1. more secure due to limited access, not using well-known ports
  2. easier implementation of advanced UI interactivity features
  3. requires installation (unless using WebStart; see below)
  4. possible to distribute load: business logic components run locally, no web browser required (see architecture drawings)
  5. more control over context (i.e. no browser compatibility issues, no platform issues if Windows-only)
  6. implementation platforms:
  1. Sun/Oracle Java Virtual Machine (JVM) based
  1. Java/Swing
  2. Scala/Swing
  3. JavaFX (Sun/Oracle alternative to Flex)
  4. Groovy/Griffon/Swing (Rails-like framework for Swing)
  1. Microsoft .Net-based: any CLI language
  2. Adobe AIR-based: Flash or Flex
(Visual issues between these are addressed below.)
Non-browser based Web App (Java Web Start)
  1. requires web server for initial installation
  2. subsequent executions local
  3. crosses lines between Applet (in-browser app) and Application (desktop)
  4. implementation is Swing or JavaFX
  5. full interactivity as in desktop app
  6. could use heavy-weight client to integrate portions of backend
  7. use light-weight client calling a higher-level API on web server
  8. Ref:
Browser-based Web App - with Plugin
  1. offers rich interactivity, near desktop
  2. avoids browser issues
  3. requires web server for download
  4. could distribute load by running business logic in client (JVM plugin), or use higher-level API on web server
  5. implementation platforms:
  1. Microsoft Silverlight: zillions of CLI languages
  2. Adobe Flash: Flash or Flex
  3. JVM: any jvm language supporting Swing
Browser-based Web App - no plugin
  1. generally less rich interactivity
  2. AJAX for partial updating
  3. Comet for server-push
Web App, no plugin - JVM-generation of pages
  1. requires app server with business-logic code
  2. relying on framework provided client-side interaction (JavaScript)
  3. implementation platforms:
  1. Java/JSP (Struts, etc.)
  2. Java/JSF
  3. Scala/Lift - what we have now
  4. Scala/Other (See Appendix A)
Browser-based Web App - no plugin, “stand alone” pages
  1. requires web server supporting a high-level API (e.g. a REST API)
  2. requires larger code base in JavaScript, either:
  1. hand coded: optionally with framework such as jQuery and its plugin family
  2. generated: as in via Google Web Toolkit (GWT) Code in Java, compile to JavaScript
Visual Issues
  1. JVM - Swing: traditional ‘native’ widget/form applications with roughly the same appearance
  2. JVM - JavaFX: much more graphic design
  3. .Net - native Windows L&F
  4. AIR - Flash or Flex components
Web Apps with plugins essentially look like desktop apps
Web Apps - without plugins
  1. jQuery -
  2. GWT: and
  3. HTML5: [N.B. there browser issues here - as in partial I.E. support]
Alternative Dimensions
App server vs. web server
The top, left box is a more traditional Swing application.  The web server would not be an app server, meaning it would not need to run a JVM.  It exists primarily to deliver the applet and its jar files.

App server with page generator (like JSP or equivalent)
In this scenario, the web pages are generated from templates and values are filled in by querying the backend business logic at page generation time.  The JavaScript code in the page manages the AJAX calls to update the pages.
App server with no web framework
In this scenario, the web pages are not generated from templates and in that sense are ‘static’. The page values are filled in by querying the backend business logic at page rendering time.  The JavaScript code in the page manages the AJAX calls to update the pages, but the knowledge of the page structure is not known by the server.  All clients use a “simplified” API such as the REST API outlined below.  No internals of the back-end system are exposed, just the data model.

Conclusions and recommendations
The app server with no web framework is clearly the most flexible architecture.  The API is simple and a variety of clients support it.  For that reason, many applications are moving to this type of implementation.  This architecture achieves greater separation of concerns in that the server has no knowledge of the client.  It is straightforward to implement the server-side and requires much less code, therefore putting less load on its host.  This architecture does not limit the client-side implementation, although it may require a team member who knows JavaScript.

None of these solutions are an order of magnitude better or worse than any other.  Any of the outlined implementation plans could work.  Each optimizes a different combination of platform support, skills usage, visual and design sophistication, etc.
Misc Issues
To accomplish userid and password authentication in a REST-world, you would pass userid and password via an https request to an API which would validate them and return an authorization token for future API calls.
Appendix A. - Scala Web Frameworks
Lift has been under development since 2007 ( and is used by such large sites as (
Cons: mentioned above
Pros: provided support for Ajax, Comet, client-side graphs (Flot)

SSP (Scala Server Pages):
More basic framework; may avoid server-side memory issues, would have to roll our own support for Ajax, Comet.
Pinky: REST/MVC glue web framework built on top of Guice and Guice Servlet 2.0.

Appendix B - REST API
A REST-notation API passes all arguments in a URL call over HTTP.  The result is returned generally in XML or JavaScript Object Notation (JSON).  A domain model which is hierarchic is easily supported and mapped to a set of URL calls.
Additional Background Notes:
Scala has been under development and in use since 2001 (

REST and JSON is an evolving area of development.. c.f.