Archives

X11 is a client/server display system that realizes user interfaces by sending asynchronous messages back and forth between a display server — that manages a display, mouse and keyboard — and clients such as xterms, Firefox, GIMP, etc. Some of the drawing, windowing, events and other operations that the X protocol supports look suspiciously like some of the things flying around in Ajax these days.

Now there are some substantial differences between X and Ajax. For one, X clients (the equivalent of the http server) open up persistent connections to the X server (the equivalent to the browser), while the ‘Ajax server”, aka the browser, has to poll the “Ajax clients” (the apps on the http server) for messages. X is typically used in a LAN rather than a WAN setting, for this reason. Persistent connections usually don’t hold up very well in a WAN context. Also, there’s no embedded scripting language like Javascript in X.

One definite similarity is that both X and Ajax don’t have any widget standards. In X you’ve got several different widget sets — Motif, Qt, Gtk, etc. — while in Ajax you’ve got a few early frameworks with their own widgets.

So, what’s to be learned from all of this? First, while user interfaces may well head in the component GUI/widget directions, we’ll likely have quite a number of different widget sets in the long run. Second, there are a few design lessons to be learned from X Windows. For example, the creation of windows with a specific look and feel is controlled by a window manager abstract factory.

Some of these design solutions may not be appropriate for Ajax, but I think it’s worth mining this trove of design solutions. Might we some day have an Ajax desktop that unifies multiple independent Ajax applications?

Update 1: Bill Scott makes a similar point (though much earlier — more coffee, I’m sure).

I’ve touched on the topic of updates and asynchronous processing before. My preferred method of performing updates between the browser and server is via a polling mechanism that returns quickly. An alternative is to open up an XHR connection and keep it open to wait for a response (or a timeout). I don’t like this method because it is wasteful in terms of sockets and threads; also, it is likely to stress stateful firewalls, load balancers, etc., and may break in lots of client environments.

Nevertheless, if you want to keep a connection open for notification initiated by the server, this is the way for now. And the Jetty 6 server has at least addressed the thread issue with Continuations.

Behind the scenes, Jetty has to be a bit sneaky to work around Java
and the Servlet specification as there is no mechanism in Java to
suspend a thread and then resume it later. The first time the request
handler calls continuation.getEvent(timeoutMS) a RetryReqeuest runtime
exception is thrown. This exception propogates out of all the request
handling code and is caught by Jetty and handled specially. Instead of
producing an error response, Jetty places the request on a timeout
queue and returns the thread to the thread pool.

When the timeout expires, or if another thread calls
continuation.resume(event) then the request is retried. This time, when
continuation.getEvent(timeoutMS) is called, either the event is
returned or null is returned to indicate a timeout. The request handler
then produces a response as it normally would.

Sockets are still consumed, though. Hopefully the next servlet specification will address some of these issues. Until that time, this may be a good workaround.

Still, my preference is to keep everything except for the display logic on the server side, and that includes handling complex communication with async processing.

Update 1: ActiveMQ can make use of Jetty 6′s continuation mechanism.

Update 2: Greg Wilkins has some more extensive thoughts on using Jetty 6 to scale Ajax apps.

A reader emailed me this old article from CNN Money discussing the concept of the webtop, i.e. that

A killer app no longer requires hundreds of drones slaving away on
millions of lines of code. Three or four engineers and a steady supply
of Red Bull is all it takes to rapidly turn a midnight brainstorm into
a website so hot it melts the servers.

What has changed is the way today’s Web-based apps can run almost as
seamlessly as programs used on the desktop, with embedded audio, video,
and drag-and-drop ease of use. Behind this Web-desktop fusion are
technologies like Ajax (asynchronous JavaScript and XML), Macromedia’s
Flash, and Ruby on Rails. We’ll spare you the technical details;
suffice it to say that these technologies are giving rise to a new
webtop that may one day replace your suite of desktop applications.

I already hate the term “webtop,” though I’ve used it myself in the past. The article goes on to discuss the various webapps that are starting to move into areas once reserved for desktop applications, then lists of a few noteworthy apps, such as 37signals campfire chat client.

The conclusion? We’ll all be doing our word processing over the web from now on.

Now I like a little bit of breathless hype as much as the next guy, but this is over the top. Yes, webapps are going to change, but there are certain limitations to the medium that will make the webtop a much tamer place:

• Reliability and performance – why aren’t most desktop apps in corporate environments served up as client/server apps? The technology is there; the kinks of client/server have mostly been worked out. License sharing could save tons of money. The benefits of reliable, centralized storage and ease of collaboration seem pretty obvious. Yet the most we see is networked storage of documents. The reason? Even on a corporate network, performance and reliability are not high enough to make client/server computing for desktop apps attractive.
• It’s more than just CRUD on speed – even after the widespread introduction of the WIMP (Windows, Icons, Menus, Pointing device) environments in the 80′s, it took a while for programs to mature beyond GUI versions of Lotus 1-2-3. We didn’t see precursors to Photoshop until a few years after the introduction of the Mac. Most webapps today are still glorified CRUD (Create, Read, Update, Delete) engines. Writing the more substantial applications will take a good bit of work, not just a few cans of Red Bull (or Jolt!, sniff).
• Writely ain’t Word – more like Wordpad. If Writely was out as a desktop app, it wouldn’t get a second look. Yes, there is a need for a Word-compatible, easier, less bloated, free word processor, but they never seem to make it. Yes, a web based word processor that saves your work more frequently than an occasional submit is kinda cool. But the truly cool part is the collaboration feature of Writely, and honestly, there are other, better solutions for that.
• Can I Use it Offline? – You’re not going to be online all the time. The moment you have desktop versions that can function independent of the server, is it still Ajax or a Javascript/Browser app with save capability?

This hype around Ajax is really starting to remind me of the first dotcom boom (See FauxJAX for a good sendup of this). I had a few venture capitalists back then asking me to look at business plans that added “the web” to their business models. My rule for evaluating these was always the same: what does the web add? Most times it didn’t change anything; it was just another marketing channel. For others, like online classifieds, it removed distribution costs. For the social networking type businesses, it made it easier and less costly to jumpstart the network effect.

So, for those going gaga over Ajax, ask yourself, what does Ajax add? If you can’t come up with a good answer, odds are it doesn’t add a thing.

I’ll be giving a talk at the Chi2 monthly meeting on Wednesday, April 26, 2006. The highlights are:

• Why web applications are they way they are and how things are changing
• First attempts: frameworks and toolkits that extend current practice
• How Ajax has turned the browser into a desktop
• Component-based GUI’s and how they cut down on Ajax Development time
• Which frameworks get it right

For more information see here. If there is a podcast, we’ll try to make that available along with the presentation.

Most web applications are still request driven, i.e. the browser makes a request and backend state is updated as a response to that request. There is some backend processing, but usually that processing is very losely coupled with the webapp, updating a backend data store.

Many more advanced apps make use of web services, MDB’s, JMS, and other approaches to perform asynchronous processing. The need for asynchronous processing in webapps has been mostly confined to some special cases, requiring extreme scalability or performance. But now with the advent of Ajax, many new webapps are going to have to perform ongoing background processing in order to update front end displays. Some of these processes are going to exceed the time you want an XHR to be open. Or maybe you want to perform some backend processing tightly coupled to the session and UI, rather than loosely tied to the persistent store.

I’ve used open source tools like Mule, ActiveMQ and the like for some of these things. It does make life a bit easier when doing async processing, but moving to these new technologies will involve a bit of a learning curve for most webapp developers. Sorry, guys, the pain isn’t over.

Ajax has brought a new focus onto many parts of the browser, but none more so than Javascript. What started out as a rip and run embedded language called "Livescript" in Netscape Navigator has evolved into a rich language that supports sophisticated OO programming and design styles. But most Javascript written today remains primitive, poorly designed and implemented — hack jobs, so to speak. The most you’ll see on many commercial sites is the Javascript divided up into procedural utility libraries. Just look at the excellent book "JavaScript Anthology" (see a very illuminating review of it here). Most of the code in the book is very procedural; that seems to be the expectation of Javascript — ignore most of its capabilities by writing little procedural snippets.

So here comes Ajax, along with tons of other tools and platforms that embed Javascript: OpenLaszlo (flash UI), Kettle (ETTL tool), and the various projects that embed Rhino, the Mozilla Projects Java-based Javascript interpreter. On their heels come an army of sophisticated and knowledgeable programmers who have different standards. These guys are relentlessly raising the bar on design and style in Javascript. The days of rip-and-run Javascript are over.

So, what’s a Javascript Hacker to do? Maybe it’s time for a second edition of Javascript Objects, a title that went nowhere in 1998.

I recently did a little unscientific comparison between the old Yahoo mail and the new Beta Ajax interface. The idea was to strap a non-caching proxy in front of the browser for a day each, clear the cache and see how they compared.

I fully expected to see the increase in requests and a decrease in request size that everyone talked about. I did see the former, but not much of the latter, as it turns out. The average request size was smaller for the Ajax version, but not that much smaller.

While this test wasn’t scientific — I just used my yahoo mail account as I usually do throughout the day — my educated guess is that the temptation to add lots of features to the new whiz-bang interface is the culprit.

Here, without further ado, are some of the facts and figures (count is number of requests. All others are in bytes):

Ajax Yahoo Mail

Old Yahoo Mail

What does this mean to you and your infrastructure requirements? Unless you exercise incredible discipline in pushing back on feature creep, you are likely to have Ajax apps that make more and bigger requests.

Remember when 1MB was more computer memory than anyone would ever need, or when car makers used the extra energy in those hybrid vehicles for greater fuel efficiency instead of more power of hybrid SUV’s?

Here’s just a little sampling of articles from the November 1983 issue of COMPUTE!’s Gazette.

• Computer Graphics – The Age Of Electronic Art
• VIC Super Expander Graphics64
• Introduction To Custom Characters For VIC And 64
• VICreations: Animating With Custom Characters

It seems every issue would have at least two articles on how to twiddle the graphical bits on the C64 or VIC-20, articles on how to make sprites dance across the screen or writing your own video game or drawing program in 6502 assembler. You had similar articles in similar magazines with the introduction of the IBM PC.

With the advent of the Mac (yes, yes, Xerox did it first), all that bit twiddling disappeared. People started wondering more about how to get windows and menus and buttons to do what they wanted them to do, or even to start developing their own controls.

Fast forward almost 23 years and read just about any blog or magazine that features Ajax articles. The articles are almost universally about nuts and bolts, nitty-gritty details, i.e.:

• Writing a server-side Ajax handler
• Creating souped up popup windows with Javascript
• Implementing fancy form controls in Javascript
• Understanding the DOM

It’s bit twiddling all over again. Perhaps it’s time to write an article on how to do Sprite animation with Javascript.

I’ve been beating the drum of component based GUI frameworks for Ajax for a while now. To understand why, I think it’s useful to look at the evolution of the desktop GUI framework and understand what makes them so successful. Over at ACM’s Queue publication, I came across an article that gives a nice overview of what an application framework does and the characteristics that make it successful. This following struck me as especially apropos with regard to most of the current Ajax frameworks.

A framework exhibits “inversion of control” at runtime
via callbacks. These callbacks invoke the hook methods of
application-defined components after the occurrence of an event, such as a mouse
click or data arriving on a network connection. When an event occurs, the framework
calls back to a virtual hook method in a preregistered application component,
which then performs application-defined processing in response to the event.
The hook methods in the components decouple the application software from the
reusable framework software, which allows each to change independently as long
as the interface signature and interaction protocols are not modified. Since
frameworks exhibit inversion of control, they can simplify application design
because the framework—rather than the application—runs the event
loop to detect events, demultiplex events to event handlers, and dispatch hook
methods on the handlers that process the events.

Inversion of Control, it’s not just for Spring anymore. Seriously, though, how many of the current Ajax toolkits — I’m not sure that with the exception of appfuse it’s correct to call them application frameworks — give you IoC? I’ll be watching to see if they make the transition to frameworks and will give credit where credit is due.

Paul Browne has nice little survey post over at O’Reilly about Ajax frameworks. All’s cool until I stumble across the following:

Echo2 – Evolution of original Echo Framework, can run in any Servlet container.
Original has cult following, but doubt if it will become the number 1
web framework.

I hear you, Paul. I remember evaluating Echo1 a long while back and thinking to myself: “why would you want to build a web application the way you would a component based desktop GUI? The behavior is so different, the lack of control, layout, look and feel, etc., etc.” My conclusion was that Echo1 was a nice design solution applied to the wrong problem.

Fast forward to today. I have DHTML, CSS, Javascript, XHR, etc. I have complete control over what shows up in the browser, anywhere, any time, anyhow. I’ve got people writing thousands of lines of rich client application code, business tier logic leaking into the browser, cat and dogs living together…you get the idea.

Now the Echo design solution makes plenty of sense. The simple report and forms beast of the early 90′s has turned into a kind of GUI desktop. Now my reaction is “why wouldn’t you want to write a rich client web app the way you would write a component based desktop GUI?” It’s a proven design. Nobody twiddles the bits by hand anymore. And when the browser wars start up again, the standards start diverging, and your Ajax apps start breaking, then the problem starts resembling that of a cross platform GUI, i.e. isolating Ajax variations in browser specific peer classes, much like AWT.

You can easily imagine running the same application as a Swing desktop GUI or a browser embedded Flash app. That’s if the design is right and makes use of what? That’s right, browser or rendering layer specific peers.

Guess who has all that today? That’s right, Echo2. Come on and drink the Kool-Aid.