Perimeter Sweep:            An Assortment of Stuff from Gary Horton

The last year has been one of intense learning around JSF for me. Some of my teammates have asked me to share my so-called wisdom, and I'll be using this blog as one part of that effort. It's been said that to really learn something, one should teach it...so I look forward to giving this a shot.

A modesty disclaimer is in order: it's only "so-called" wisdom because I've got a great deal more to learn about JSF (and web development in general), so everyone's feedback, critiques and corrections are invited.

For starters, it's useful to gain some historical insights...so I start with a quick look at the prehistory and subsequent evolution of web development. With this and all subsequent posts around this topic, I'll be generalizing quite a bit, in the interest of publishing quickly; if you feel something has been omitted or misrepresented, you are invited to add to the discussion.

So, for my first generalization: the topic here is "presentation technology". My second generalization is that there are two types of presentation: web-based and not web-based. Concerning the forces at play motivating the evolution of these technologies, I'll do a broad-brush to capture what has struck me as essential. This includes the aspects of user experience, deployment and standards, with brief discussion around the tradeoffs that web-based vs. non-web-based approaches bring to each.

In the early days (defined as "long ago when my career was young"), graphics-powered desktop systems enabled the beginning of the "rich user experience". Various systems and toolkits emerged supporting both local and remote GUIs, and there is today an abundance of applications still using these approaches (X Windows, Motif, Swing, Visual Basic, etc.). Let's start with these and elaborate a bit on the user experience, deployment and standards aspects:

On the plus side, user experience is typically quite good: these GUIs provide interactive, dynamic content, with good responsiveness - especially when deployed locally. X Windows is an example of what I mean by a remote deployment (display information is transported over the network), and responsiveness in this setting is not always good. No surprise here; shipping bits over-the-wire is almost always the bottleneck in the responsiveness pipe. While delays might also be seen with a "local" GUI (display logic is installed on the user machine) that gathers its content from a remote data source, the impact here can easily be mitigated since the GUI can still be responsive if, e.g., the content retrieval is done asynchronously, i.e. in a separate thread. As it turns out, this arrangement can be exploited to provide constant, predictable response times on the display client independent of server activity with a "database in the middle" architecture; but that's a digression I'll look forward to writing about later. My main point here is that responsiveness can most easily be optimized with a locally installed GUI.

In either deployment, there are distribution issues: local GUIs must be installed directly on the user's machine (a so-called "fat client"), and remote deployments require some level of installation on the user's machine to support the client-server idiom; e.g., an X11 server is needed in the X Windows case. Managing this distribution has non-trivial maintenance costs; the larger one's audience (e.g. intranet vs internet), the more of an impact this will have. To address the timely update and distribution of fat clients, we've seen solutions ranging from sneaker-net (here-and-now solution but very slow, very difficult to manage versioning, etc.) to things like self-updating applications (more sophisticated but, at first, lacking in standards and still requiring the initial installation). Deployment costs in this setting most likely limit one's audience to the intranet only.

Finally, there has been the issue of standards. With widespread adoption of Java, platform-independent GUI development has been largely realized; however, user-facing Java applications (applets, AWT, Swing) have, fairly or not, been regarded as slow and clunky. I've personally never thought of the presentation layer as Java's strength, but it was originally marketed with that as the focus, and unfortunately this has left an indelibly negative impression around Java in some camps. For this and/or whatever other reasons, desktop Java has made some inroads but is hardly what I would call "ubiquitous" or "compelling". Aside from this platform-independence issue (which is, arguably, a deployment topic), there is a need for standards around the presentation-layer programming model. When we standardize here, our investment in learning curve can be reapplied in subsequent projects, we provide for modular component-based programming that encourages reuse, we build communities of developers that share knowledge bases and design patterns, ... the list goes on, I'm sure. It's probably pretty safe to say that standardization here would be a good thing. However, desktop presentation developers use a wide variety of proprietary or at-best-de-facto-standard toolkits, with widely varying programming models and APIs; I'm unaware of any widely embraced standards in this area.

Now let's move on to web-based presentation. There are many excellent writeups on the history of the Internet and development of the World Wide Web (WWW) as an Internet application; for my purposes here, the main takeaway is that an entirely new basis for presentation was provided by (1) opening the Internet to commercial interests in 1988, (2) the invention of HTML, HTTP, and web browsers in the early 90's, and (3) resultant widespread public consumption.

With the WWW, internet-wide deployment can be realized (open up your audience to...the world); while web browsers still must be installed on the user machine, they are typically included in the desktop OS, reducing the deployment cost (and time) to zero. The ubiquitous web browser is now taken for granted.

Building on the WWW, benefits can be gained from use of standards - for a beginning, HTTP, TCP/IP and HTML lay the foundation, and further evolution has moved from there: the subsequent layers above this basis have standardized over time to bring us to JSF.

While not lost in the shuffle, the WWW user experience is something of a setback. Dynamic interactivity (e.g. drag-n-drop, automatic screen refreshes, etc.) is, until recently, lost altogether, and responsiveness is known to suffer. In fairness, this is as mentioned always a risk for remote deployments, which is usually what your web browser is part of - although this can be mitigated with asynchronous processing, database-in-the-middle, etc.. Overall, while the deployment and standardization advantage goes to web apps, non-web-based locally-deployed GUIs hold a strong edge with user experience. But, this is changing with emergence of AJAX and related technologies that leverage asynchronous behaviors. In fact, with these new approaches, the web-based experience has potential to evolve into a rich, responsive one.

You have my apology for such generalized content; I've omitted a great deal. My purpose here is to simply set the table for a TOI (uh, a general one) around JSF, and that series will continue "soon". Next up is a closer look at web-based technology per se to fashion a backdrop, moving into JSF and Sun's implementations of JSF in particular, and revisiting my current learning curve around AJAX to share still more so-called wisdom...